should not be unduly constrained; components should be reused when possi- ble; requirements evolve. But environment integration produces ...... returned by the fh-st method to terminate. ..... GARLAN, D., AND ILIAS, E. Low-cost, adaptable.
Reconciling Environment Scftware Evolution
Integration and
KEVIN J. SULLIVAN and DAVID NOTKIN University of Washington,
Seattle
Common software design approaches complicate both tool integration and software evolution when applied in the development of integrated environments. We illustrate this by tracing the evolution of three different designs for a simple integrated environment as representative changes are made to the requirements. We present an approach that eases integration and evolution by preserving tool independence in the face of integration. We design tool integration and we design tools to implicitly invoke relationships as separate components called mediators, mediators that integrate them. Mediators separate tools from each other, while implicit invocation allows tools to remain independent of mediators. To enable the use of our approach on a range of platforms, we provide a formalized model and requirements for implicit invocation mechanisms. We apply this model both to analyze existing mechanisms and in the design of a mechanism Categories
for C++.
and Subject
nance—enhancement, K.6.3 [Management Management—software
General
Descriptors: extensibdity;
of
D.2.7 [Software D.2. 10
Computing
development,
Engineering]: [Software Engineering]: and Information
software
Distribution
and Mainte-
Design—methodologies:
Systems]:
Software
maintenance
Terms: Design
Additional Key Words and Phrases: Abstract behavior type, behavior abstraction, component indepmdence, environment integration, event mechanism, implicit invocation, integrated environment, mediator, mediator\ event design, software evolution, tool integration
1. INTRODUCTION An integrated environment is a collection of software tools that freeing the user from having to coordinate them manually. programming ging, the
environment
for example, editor
scrolls
might to the
with ensure
tools that
corresponding
for text when
editing,
compiling,
the debugger
source
statement.
reaches
work together, An integrated and debuga breakpoint
Integrating
these
This research was funded in part by NSF grants CCR-8858804 and CCR-9113367, AFOSR grant 89-0282, Digital Equipment Corp., Xerox Corp., Tokyo Institute of Technology, and Osaka University. K. Sullivan was funded in part by a GTE fellowship. An earlier version of this paper appeared in the Proceedings of SIGSOFT90. Authors’ address: Department of Computer Science and Engineering, FR-35, University of Washington, Seattle, WA 98195 permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. 01992 1049-331X/92/0700-229 $01.50 ACM Transactions on Software Engineering and Methodology, Vol 1, No 3, July 1992, Pages 229-26S
230
.
tools
K. J Sullwan and D Notkln
relieves
the
user
from
the
tedium
of locating
numbers, and supports instead the primary Integrated environments support tasks
source
files
word processing systems integrating editors, outlining tools, and spelling checkers; financial systems integrating spreadsheets, databases,
and tax preparation
compilers,
editors,
grating analysis
Managing
the are
software
system:
should
complexity similar
integration components. Integrated gration
requires
complex manage
and
into
integrating
from
inte-
planning
is hard. medium-
and
Many
of the
to large-scale
implementation
should
coordination
designed
the tools
decisions
be reused
debugger
approach
of tools,
by merging
themselves.
and a debugger,
the
tools. In the worst complex integration
This
any
be satisfied;
components
fine-grained are often
an editor
editor
must
constrained;
life-cycle,
in
include style and portfolio
environments
environments
encountered
line
when
possi-
evolve. But environment integration produces an additension. Software evolution, which is unavoidable in when system components are largely independent; but
relationships
between
environments
software
of integrated
requirements
tools
programming
sW%ware development
of the
to those
not be unduly
ble; requirements tional, complicating practice, is easiest
tions.
and
tools for many phases through retirement.
difficulties
the
tools;
debuggers;
and
task, finding the bug. in many domains. These
case, each relationships
also distributes
might
This
can
of system
for the
be designed
regarding
inte-
of the relationship
lead
tool interacts in addition
decisions
hence
responsibility
Knowledge
for instance,
components.
and
into
both
to unmanageably
with to its
every other to own basic func-
integration
through-
out the environment: tool A has to know how it relates to B and also B to A, for instance. Furthermore, intermingled tools are statically sculpted to participate the
in
specific
connections
relationships. among
complicate Another
software approach
nents
encapsulate
that
an editor interacts
and with
tools,
The
evolution. is to design tools
resulting
and the
integration
in order
complexity
distribution
relationships
to effect
of individual
of integration
their
as separate
integration.
tools,
concerns
all
compo-
For example,
a debugger might be wrapped in a third component the user and manages the underlying tools on the
that user’s
behalf. Although the tools themselves remain independent, encapsulated tools cannot be accessed independently. This design technique complicates evolution by making it hard to change, add, and remove tools and integration relationships. We illustrate these ideas more carefully in Section 2, through three designs for a simple specification. These design styles arise in part because system specifications often merge tool and integration concerns or frame integration explicit tool invocations. To ease evolution, then,
requirements in terms of we need to structure both
specifications and designs to reduce the complexities that result tion. Our goals should be to keep tool complexity proportional to localize decisions regarding both tools and integration and to do this while also facilitating tool integration.
ACM
TransactIons
on Software
Engmeermg
and Methodology,
Vol. 1, No. 3, July
from integrato function, relationships,
1992.
Reconciling We have integration
Environment
Integration
developed an approach and software evolution
invocation mechanism. this approach yields
and visible
tool components
components,
which
of keeping
tool
relationships separately from to these integration components
a system
composed
plus a set of separate,
we call
mediators.
components
.
231
that appears to reconcile environment to a reasonable degree. The key to our
approach is to define tool integration themselves and to connect the tools an implicit Applying
and Software Evolution
visible
of a set of independent
or externalized,
At its heart,
in contrast
the tools through
we stress
integration
the importance
to encapsulated
and
indepen-
dent in contrast to intertwined. New integration relationships are easier to design when tool components are visible, while tool independence eases both evolution and integration. 1 In Section 2 we present an example that illustrates the sorts of problems encountered
when
of integration we
present
these implicit
traditional
and our
designs
evolution.
In
approach
conflicting invocation
are
Section
and
show
confronted 3, in the
how
it
interests. We also discuss more fully. In particular,
mod el that
can serve
mechanisms.
We
as a starting
discuss
point
additional
with
eases
the
that
4 discusses
integrated
present and
how
in the design
systems
that
7 are devoted
better
to a discussion
invocation
model
understanding
discuss
other
ponents
they
discussion
systems
several
separate
then
specification integration
approaches
challenge
each the
tend
briefly
Sections
mechanisms
our
to gain
In Section from
a brief
6
6 we apply
the
summary
a
7 we comand
a
of our effort.
to produce
cate evolution, either integration concerns.
design
with
each
by encapsulating
Transactions
framework. components
to tool reusability,
on Software
of two
are intended
in a simplified
JInde pendence is also closely related this article.
integrated
environments
that
evolve. We illustrate this by applying for a simple integrated environment.
enhancements
and evolution
ACM
5 we
approach.
DESIGN APPROACHES
design
and
approach.
Section
relationships 8, with
the
requirements
In Section
existing
integration
and limitations
our
this
invocasketch
to meet
and differences.
in Section
are hard to change as requirements thres such approaches to requirements We
work.
invocation
implicit
with
In
using
key similarities
We conclude,
of the strengths
2. TRADITIONAL Traclitional
that
generate. built
of related
to analyze
of their
relate.
to
we have
between
We also
can be applied
tend
that
example,
tension
of implicit
requirements
approach
environments
several
imp] icit
our
combination
of this
our use of mediators and we present a simple, formal
tion mechanisms should meet to support our approach. design of our mechanism for C++. In Sections 4 and 5 we summarize our experiences Section
the
context
Engineering
enhancements.
The
to capture
aspects
All three
key
designs
or by merging
basic of
complitool
and
but we do not stress this connection
and Methodology,
Vol. 1, No. 3, July
in
1992.
232
.
2.1
Initial
K. J, Sullivan and D Notkm Specification
The two “tools”
in our environment
manage
a set of points
and a set of pairs
of these points. The user can create points and, given two points, can create a pair. The user can also insert and delete points and point-pairs into and from the point and point-pair sets respectively. In addition, we specify an “integration relationship” between the point and point-pair sets: the two sets should form a graph. We thus will be justified in referring to points and point-pairs at vertices The
and edges,
vertex
methods
(i.e.,
respectively.
point)
for vertex
type
creation,
testing equality with another references to the two vertices getting
these
types
export
vertices
and
methods
stores
a pair
for getting
and
of
coordinates
setting
the
vertex. The edge (i.e., and exports methods
for
testing
equality
for set creation,
with
element
and
coordinates
point-pair) for edge
for
type stores creation, for
another
insertion,
exports and
edge.
deletion,
The
set
and mem-
bership testing, and for getting an iterator object that can return each element in turn. To the vertex-set and edge-set tools (which we denote VS and ES) we add a third,
a user interface,
vertices ment
and
edges.
through This
of the integration
ing an edge into
which
structure
it possible
relationship—that
ES for which
in VS or by deleting
the user can create,
makes
neither
a vertex
from
the sets form or only
VS upon
insert,
the
require-
a graph—by
insert-
one of the vertices which
and remove
to violate
one or more
of the edge is edges in ES is
incident. To
maintain
integration
the
required
relationship
constraint
G that G(VS,
is maintained. invariant—one
we
ensures ES)
integrate
that
the
tools
under
an
the invariant
= ES c VS
VS
X
Many different policies could be defined to maintain this that undoes the deletion from VS of any vertex on which
edges in ES are incident, for example. In this case we specify a policy preserves the user’s last action: when a vertex is deleted from VS, delete ES all edges incident the that
membership is not already
on that
vertex;
when
in VS of the
edge’s
vertices
an edge is inserted and insert
into
in ES, VS
that from check
each vertex
a member.
We often specify a given integration relationship as a combination of an invariant and a policy to maintain this invariant in the face of changes. Often, these policies have to satisfy additional requirements, such as preserving rather than undoing the user’s last change. 2.2 Two Representahve We now with
consider
respect
Enhancements
two
enhancements
to each forthcoming
to the
design
specification,
in order
which
we discuss
to assess the robustness
of
these designs with respect to evolution. The first enhancement is a change to an integration relationship. We enhance G to support lazy, in addition to eager, maintenance of the graph relationship. The new invariant is G’(VS, ACM
TransactIons
on Software
ES)
Engineering
= (eager
~ G)
and Methodology,
V lazy. Vol
1, No
3, July
1992
Reconciling Our
new
make
policy
for
G’
Environment is to apply
no compensating
invariant vertex
when
‘I’he
second
integration a rlew
updates
toggling
not already
from
a member
tool,
which
new
incrementing,
is that
policy
for
a tool
C, which,
and
to the
the value
the cardinality
to the
VS
any
set of tools
and
into
by integrating
an integration and
mode,
is incident.
ES
illustrate
integer
233
to reestablish
by inserting
We
.
in eager
and
is a change
both
reflect
exports
relationmethods
of this
number.
of
We thus
VS.
for
The new define
an
invariant
C(N,
Our
mode
environment.
and getting
C with
G when
mode,
any edge in
a nonnegative
N should
for
to eager which
adding
N stores
relationship
lazy
the
decrementing,
relationship integration
policy in lazy
we consider in
involves
tool
the when
upon
enhancement
relationships
shipp. The
Integration and Software Evoluhon
VS)
again,
=
N
retains
=
IVSI.
the
effects
of user
changes,
is to
increment or decrement N whenever a vertex is inserted into or deleted from VS, and to insert a vertex into or delete one from VS whenever N is changed. 2.3 Three Traditional
Designs
We now apply The resulting
three traditional design approaches to the basic designs are intended to reflect characteristics
practice
these
when
components
design
for the vertex
do not discuss
them
approaches
are applied.
and edge types
any further.
The
that
design
All
three
are defined of the
user
requirements. that arise in designs
include
identically, interface
so we differs
in
each case, but is always defined directly in terms of the visible components; we also omit further discussion of this component. ES, and N and the integration The components realizing the tools VS, relationships design
we focus 2.3.1
G, G’, and C, on the other
approach on these
applied.
hand,
differences
vary
considerably
are at the heart
based
on the
of the matter,
so
components.
Encapsulation.
components,
These
The
G, VS, and
first
design,
shown
ES. The components
in Figure
I,z defines
VS and ES realize
three
the tools
VS
and ES, while G realizes the integration relationship G through encapsulation of VS and ES.S The methods exported by G call VS and ES to insert and delete vertices and edges on the user’s behalf. Since G encapsulates VS and When
ES, only G’s methods one of these methods
in iZS are incident,
for example,
are visible to the user interface. disrupts G, by deleting a vertex on which the method
reestablishes
edges
the relationship
by
2In the figures discussed in this and the following section, components are represented by olouble-framed boxes and the methods they export by single-framed boxes. Shaded boxes denc]te hidden components or methods not accessible to the user interface, while unshaded boxes denote visible components or methods. Black arrows denote explicit, and grey arrows, implicit method invocation. The tail of an arrow designates the method making the invocation, and tbe head, the method that is invoked. If the head points to an entire component, one or more methods in that component are invoked. For clarity, only invocations made to maintain integration relationships are represented, in contrast to those implementing basic tool functions. 3We use a boldface font to denote specification components such as VS, and an italic font for corresponding design components such as VS. ACM
Transactions
on Software
Engmeermg
and Methodology,
Vol. 1, No. 3, July
1992.
234
K. J. Sullivan and D. Notkin
.
G ES_Delete(e)
[ Figure
invoking
a separate
VS. Delete(u) ensure
the
deleting
any
incident from
design
method
u from
consistency
components ods. This
update
to delete
is fairly
clean.
Separate
the
design,
VS and
does invoke relationship this,
from
aspects
G—are from
of each
ES
update
meth-
of the specification-the
represented
are independent
VS to ES,
necessary
to of ES other
separately;
other
and
to VSJ or from
tools and within
of G: there
VS or ES
are
to G. G
VS and ES explicitly, but this is reasonable since G manages the between them. However, VS and ES are encapsulated by G, and
as we shall
First,
ES
these
calls
G. G-VS-Delete(u)4
iterates over the edges VS and ES to prevent
G by bypassing
and ES and the relationship
G. VS–Delete(u)
it calls
This method u. G encapsulates
VS
no invocations
by G. After
defined
of G. on
1
1
VS, for example,
invalidating
VS_lnsert(v)
though,
see below, we note
complicates
that
integration
designing
of new tools.
G as a separate
component
G eases
evolution by localizing the effects of changing G to G’, as shown in Figure 2. We add a mode-bit (LazyFlag), a method to switch modes, and we modify the update methods are reasonable:
to maintain the they are implied
and
change
the
overall
to
the
new relationship by the change
design
is
proportional
change to the specification. Notably, VS and ES in order to change the relationship between them. The
second
encapsulates designed into
change, VS,
shown
which
as an independent
G, where
VS
in
makes
is visible.
Figure it
hard
component Thus,
to
do not
3, is harder, to integrate N,
we
G’. These changes to the specification,
but
G’s
size
with
we have
of the
to change
however, N
then
expand
the have
because
VS.
to migrate
interface
with
N
public
methods to change N and with private update methods to maintain (as well as G). The new version of G really represents a composition G and C, as the new name GC indicates.
i Our method
G
N can be
C of
names reflect the component defimng the method and the function performed. M defined in G and deletes a vertex from VS by calling VS. Delete(u); G.G_ VS_Delete(v) maintains the relationship of G in the face of the deletion of a vertex from VS, for example. Update methods, such as G. G–VS–Delete(u), are not strictly needed. This code could be placed directly into the methods exported from G. However, the separation makes the code and the explanation clearer by Isolating the basic tool activities from the actions needed to preserve G.
G. VS-Delete(u)
ACM TransactIons
on Software En~neermg
and Methodology,
Vol
1, No. 3, July 1992
Reconciling
Enwronment
Integration and Software Evolution
.
235
G’ VS_lnsert(v)
ES_Delete(e)
1
~~1
+
t
t
G’_ToggleLazyo
G’_ES_lnsert(e)
G’-VS_Delete(v)
I
I
+
II 1~1
Vs I
i
II
Lazy Flag
ES
II
Figure
2
GC N_lncremento
VS_lnsert(v)
N_Decremento
VS_Delete(v)
ES_Delete(e) --l ES_lnsett(e)
I
T
+
+
GC_N_lncremento
GC-ES_lnsert(e)
GC_N-Decremento
GC_VS_Delete(v)
I+!&-”pi
N
Vs
Figure
When faced with the integration thus forces a merging of separate
ES
3
of a new tool, the encapsulation concerns. Maintaining C should
is not possible knowledge of either ES or of G, but this separation hides VS. When N is decremented the update method of GC.GC.N.Decrement must
not only
edges
incident
delete
a vertex
on the
to restore
deleted
vertex.
sert(.e) and GC. GC–VS–Delete(v) not been changed at all.
must
because
G
( )
C, but The
approach not require
must
also access ES to delete
update
methods
be modified,
GC.GC–ES–In-
too, even
though
G has
While this design seemed promising integrated. Integrating N substantially
at first, it degrades when a new tool is increases the complexity of G and
damages
specification
the correspondence
and C in GC. These This
approach
is typical.
prod ucing the initial plify this approach. tures,
but
integrating other major
these
factors
between further
complicate
Indeed,
one can easily
and design
future
by merging
anticipate
a programmer
design given the original specification. Unix tools They often have rich and well-modularized inner
are hidden
from
other
tools.
This
G
evolution.
decreases
exemstruc-
the potential
for
Unix tools without merging their implementations or making changes to expose internal representations and activities.
2.3.2 Hard- Wiring. components, VS and ACM
The second design, shown in Figure 4, defines two ES, both of which export methods to the user interface.
Transactions
on Software
Engineering
and Methodology,
Vol. 1, No. 3, July
1992.
236
K, J, Sullivan and D. Notkin
.
mm
Delete(e)
I
Figure
1
I
Iterateo
4
Vs
m ES
Insert(v) Member(v)
Delete(v)
Delete(e)
Iterateo
1
Iterateo
G’_VS_Delete(v)
1-
G’_ES_lnseti(e)
1
LazyFlag
t G_ToggleLazyo
Y
II
t
Figure
To maintain
G, VS and
VS. Delete(u)
deletes
making
appropriate
edge is added,
ES
invoke
U, it invokes calls
each
other
directly.
VS. G-VS-Delete(v),
to the exported
ES. G–ES–Insert(
5
e ) calls
methods
For
which of ES.
VS to maintain
example, maintains
Likewise,
after G by
when
an
G.
In contrast with the previous design, this one exposes VS and ES in an attempt to ease integration of N. In doing so, however, it sacrifices the explicit representation of the relationship G in the design and creates explicit invocation dependencies between VS and ES. These structural problems complicate both enhancements. As shown represented
in Figure explicitly.
5, adding a lazy mode Instead, both VS and
to G is hard because G is not ES have to be modified when
the relationship between VS and ES is changed. This distribution of G also makes it hard to know where to place the lazy-mode bit and associated methods. In Figure 5, the change is made to VS, but the change to ES would be symmetric. ACM
TransactIons
Distributing on Software
the Eng-meermg
change
between
and Methodology,
the Vol.
components
1, No. 3, July
1992
would
be
Reconciling
Environment
Vs
237
ES
Insert(v)
•1
.
Integration and Software Evolution
Insert(e)
I
Member(v)
Member(e)
Delete(v)
Delete(e)
Iterateo
1
Iterateo
1
GC_VS_Delete(v)
GC_ES_lnsert(e)
GC_VS_lnsert(v) I
GC_N_Decremento
GC_N_lncremento
Figure
I
6
confusing. Creating another component may be the best solution, but ES would still have to change and the interactions among the three ne.mts would be similar to those in our design. Furthermore,
as shown
in Figure
6, this
design
tion of N, even though VS is exposed. VS must relationship C. Moreover, the modified design
does not ease the integra-
still be modified merges aspects
VS, further decreasing the independence of VS and spondence between specification and design. Software
designs
based
on this
approach
VS and compo-
abound.
to handle the of C and G in
complicating It is hard
the
corre-
to cite specific
systems, but not hard to find advocates of this approach. Coad and Yourdon’s object-oriented analysis method, for example, is based precisely on subsystem (subject) integrated
composition environment
produces
structures
makes
it hard
toc,ls, since 2.4 The
by explicit invocation [6]. Using this approach for an would be inadvisable. It complicates evolution and that
to change
each may
degrade and
be tightly
rapidly
as enhancements
add relationships intertwined
and with
are
made.
also to replace
many
It
or reuse
others.
Events third
design,
a variation
pklCe of the explicit
invocations
of the
second,
between
employs
VS and
implicit
ES. Briefly,
invocation implicit
in
invoca-
tion occurs when one component announces an euent that it has defined to which other components have attached methods to be executed. The key the component making an implicit invocation—the one that point is that clei~nes
invoked Sections
event—need not know when it announces the 3 and 6.
the
ACM
Transactions
on Software
the names or even the number event. We discuss this topic
Engineering
and Methodology,
of methods further in
Vol. 1, No. 3, July
1992.
238
.
K. J. Sullivan and D, Notkin
w
ES Insert(e)
Delete(e)
Member(v)
Member(e)
Iterateo
Itereteo
[
I
G.ESebtserLed(e)
G_vS_Deleted(v)
Figure
In this that
design,
they
shown
announce
ods are operates
similar on the
ponent.
To
in Figure
when
7,s VS and ES are extended with or deletions succeed. The update
insertions
to those in the component that
complete
the
7
previous defines
design,
we
it
design, rather
associate
events meth-
but in this design than on the other the
each com-
ES. G–VS–Deleted(u)
update method in ES with the VS. Deleted(u) event of VS and similarly the update method in VS with the edge addition event of ES. This design has characteristics similar to those of the previous one. Changing
G to G’
distributed
poses through
exactly
the
VS and
same
ES,
problems.
making
The
representation
it necessary
to change
of G is both
compo-
nents to change the relationship between them. Implicit invocation fundamental affect on the difficulty of making this change. This design does allow N to be integrated with VS without changing shown in Figure 8, but not without maintain C when VS changes, we events
of VS. In contrast,
delete
a vertex.
remains
This
independent,
independence
of N
when
yields but is to add
sacrificing associated
N changes,
a hybrid iV
it invokes
hard-wired
does
update
not.
and
An
N. But this requires changing VS. Thus there is no completely satisfactory
5Events
are
Implicitly event-method ACM
drawn
invoked
as
association
TransactIons
darkened
is shown
to methods
on Software
boxes;
in tabular
the
form.
VS explicitly
alternative
way
to
to add
that
preserves
with
integrate
the
events
a new
or
VS
design.
of
tool.
tool and integration concerns, and the relationships (G and C) in VS.
connection Tracing
the
between connections
events from
and
methods
events
is helpful.
Engineering
VS, as
of N. To in N with
event-based
to VS, associated
methods
Furthermore, both alternatives merge one that changes VS merges multiple
the independence update methods
has no
and Methodology,
Vol.
1, No. 3, July
1992,
through
to
be the
Reconciling
Environment
Integrahon and Software Evolution
w
.
239
ES
Insert(v)
insen(e)
Delete(v)
Delete(e)
‘a
Member(v)
Iterateo
IL-+
G_ES_kwwtad(e)
II
1
G_VS_Deleted(v)
N
I
Increment
‘~] Dacremento
C_VS_Deleted(v}
C_VS_lneerted(v)
Figure
Many
contemporary
include
FIELD
integration
to
example, takes views explicitly
(MVC)
maintain
this
section
we
present
evolution
of integrated environment.
nents
designed
or a Unix
As in the G,
These
approach.
invoked,
tools
relationships.
implicitly
update
MVC,
invoke
views,
for but
approach We
approach
program.
defined By
illustrate
is based
independent
appears it
tools,
and
independent
ease
the
a design
for
separate
implicit
compo-
invocation.
such an abstract we mean
other detail
to
with
on mediators,
as a unit,
invoke any component our approach in greater
that
data
a component
than itself. and discuss
By type, that
Following our the role played
invocation.
3.1 An Improved
and
models
environments. Our
a component
does not explicitly desj gn, we describe by implicit
implicitly
integration
a design
to integrate
we mean
an object,
When
specified
this
[5], and the Smalltalk-80
EVENT APPROACH
the graph sepcwate
[21].
the
take
SoftBench
the hybrid approach: invoke models.
3. THE MEDIATOR/ In
frameworks
[27], the Hewlett-Packard
Moclel-View-Controller themselves
8
Design
encapsulation-based
as shown ACM
in
design,
Figure
TransactIons
9. VS
on Software
we define and
ES
Engmeermg
three
realize
components, the
and Methodology,
tools
and
VS,
ES,
provide
Vol. U No. 3, JUIY 1992.
240
.
K, J Sullivan and D. Notkln
w
ES
Insert(v)
I
Insert(e)
G_ES_lnsefted(e)
Delete(v)
Delete(e)
I
Member(v)
Iterateo
J
e methods
the
G and
called
provides
tionship.
In contrast
or ES.
Instead,
tee that
update
methods
ES.
G in turn
the
encapsulation
invocation
a
as
earlier
C as a mediator is deleted
from
and
ES
ES
G and
c,
then
which
Figure which
10
depicts
would
ES,
have
and
compose.
N
More
environment
our been
the
first
eases
both
because
implicitly
be
relationships:
{ }, {G},
between
implicit
easier
{C}, and
In
addition,
by
and
N
or
{G, C},
design
a
both
C, respectively. simultaneously, In
this
understand, the
and
VS. When invokes
and
mediators
following
and
design,
reuse,
removing
of
G
designing allows us to
events
G and
to
any
in
is localized
approaches.
adding
{G’},
change
the
enhancements
previous
provide
specification
replaces
with
announcement
to restore
simply to
VS and
of
G. This
relationship
the
event
both
thus
by
changed
N the
independent,
we associate
design
invoked
the
with
under
importantly,
correspondence
is
VS
to guaran-
events
to reestablish
in
ours
design hard
are
can
integration
C that
design,
deletion
rela-
encapsulate
not
design.
G is easy
VS, for example, ES and update
relationship
integration
Specifically,
and
separate component, as in the first design. a component N that announces appropriate
design
the
the
G does
as necessary.
ES in this designs,
I
as in the third
VS and
VS
of
Changing
vertex
VSJ
G
lterateo
realizes
this
insertion
the
invokes
VS and
to of N.
called
with
G
design,
invocation,
are G
by
G by
contrast
in
of
explicitly
of
integration
implicit
I
to maintain
used
earlier
Member(e)
9
interface;
methods the
methods
update
N
with
we use
the
In
update
the
user
the
by
Figure
[
{G’,
C}.
is preserved,
the
subsets
of
Finally,
the
easing
future
enhancement. In
review,
the
independent and
ES
VS and maintain
first
design
components. made
ES G.
ACM TransactIons
it
hard
cast This
to integrate
G as a separate eased N.
to ease integration
of N,
This
both
made
it
hard
on Software Engineering
component
evolution The but to
of
second
G,
but
and
intertwined change
and Methodology,
G
and
third
designs
these and
V
and
encapsulating
to
Vol 1, No 3, July 1992.
as VS
exposed
components
integrate
E
N.
to The
Reconciling
m Member(v)
Environment
Integration and Software Evolution
.
F====
z “’E&Ed
1 II
241
Delete(e)
Member(e)
Lazy Flag
Iterateo
ToggleLazyo
1
II
c C_N_Decrementedo
C_N,Jncrementedo
Event
Method
ES.inserted(e)
G’.G_ES_lnserted(e)
VS. Delfled(v)
G’.G_VS_Deleted(v)
VS.lnsertad(v)
C.C_VS_lnserted(v)
~
VS. Dak4ed(v)
C.C_VS_Deleted(v)
N.lncrementedo
C.C_N_lncrementedO
N. Decrc!mentedo
C.C_N_Decrementedo
I
Figure
third
design
ES.
It
regards tool
used
also it
and
Our
had
the
truth, tors
notion
and
that
they
only
G and
to preserve
integrated
problems
positive
relationships
independent
tile
same
be
10
the
without
as the
second
aspects
as separate visible,
it
but
failed
in
other
to separate
from
each
components,
which
eases
of these. and
both
we
evolution
We
and
design
VS and
keep
tool
ES
integration.
and Implicit Invocation we sometimes mediators
represent
C, for example,
encounter
represent
a new could
usage
when
a new
presenting
this
of existing
be implemented
mechanisms. as objects
approach
mechanism.
programming
The
or Unix
In
mediatools.
are first-class design and state and invoke tools as
to maintain complex relationships. When implemented as objects, respect tool encapsulation boundaries. They can export abstract announce their own events, and be composed in arbitrary ways.
For example, be treated
VS,
because
This has several advantages. Since mediators implementation components, they can maintain necessary they also interfaces,
of VS and
independence
changing
concerns.
A misunderstanding is
invocation to
combines
Why Mediators
3.2
N
integration design
integration both
implicit
allowed
‘E /
they
can be used within
as tools to be integrated ACM
TransactIons
on Software
designs
with
other
Engineering
of larger tools.
components,
Finally,
and Methodology,
they
and can
can be used
Vol. 1, No. 3, July
1992
242
K. J, Sullivan and D, Notkin
.
in existing
languages
and on existing
platforms.
mechanism, but an approach to structuring Taking full advantage of our mediator-based however, ability
without
an implicit
of explicit
nent
on the
invocation
invocation
component
alone
programming
implies
invoked.
The
Mediators
abstraction.
dependence
reason
mediators
that
relate
them
dence and, as shown in Section The availability of an implicit supported
across
a wide
the invoking
to other
components,
decreasing
of languages—can
be used
dependencies. Specifically, the invoking component simply it is the component whose method is to be invoked that name
of the event.
Since
the invoking
component
compo-
component
from the component that would have to explicitly
2, complicating evolution. invocation mechanism—an
range
a
The avail-
of an invoking
is that
must import the name of the method to be invoked defines it, In a mediator-based design, components invoke
do not represent
environment designs. design approach is impossible,
indepen-
abstraction
not
to reverse
such
exports an event; must import the
does not import
the names
of the methods that it invokes, it can remain independent. This allows the designer to distinguish between situations in which a component must communicate and those in which it may communicate. We
can
now
relationships each other. the
present
We then
dependence
when
tool visibility,
an Implicit
still
resulting
between
Invocation
design
integration of tools
mediators
to eliminate
ensuring
that
combination
representation
a new
We
dependence
invoke
while
The
the conflict
is not
a nutshell.
to eliminate
to implicitly
and separate
3.3
invocation
in
on mediators
degree,
Implicit
tools
necessary.
to a reasonable
Developing
approach components
design
of tools
ods are invoked dence,
our
as separate
update of tool
of relationships
integration
on
meth-
indepenreconciles,
and evolution.
Mechanism idea.
Many
mechanisms
supporting
this
abstraction have been designed and are in use. These include, among many others, the LOOPS active values system [32], which is intended to support program debugging and simple graphical view consistency-maintenance; the change/update
protocol
of Smalltalk-80
to support complex graphical (MVC) mechanism, intended as a mechanism relational
triggers
constraint-based A formal
in
AP5
[7],
used
by the
Model
View
views; the FIELD message for integrating Unix-based
intended
to
support
declarative,
Controller multicast tools; and relational
programming.
model.
Despite
the
diversity
of purposes
abstract these mechanisms oped a minimalistic formal
have key underlying framework to try
both to better understand designing new mechanisms. We characterize implicit
existing
mechanisms
invocation
and
designs,
in
the
similarities. We have develto capture these similarities, and
mechanisms
as a starting in
terms
point
of a set
for E
of
events, each of which can be announced; a set M of methods, each of which of methcan be invoked; a mapping EM: E ~ 2 ‘1 from events to multisets ods; and an event announcement procedure A that invokes all the methods AC!M TransactIons
on Software
Engmeermg
and Methodology,
Vol
1, No
3, July
1992
Reconciling associated
with
characterize terms
a given
the
of several
Additional
explicit
design.
gramming
dual
abstractions. We
that
thus
such
.
is announced.G
invocation model
243
We thus
mechanisms
as the basis
in Section
to this
requirements to each
in
for the
6 we apply
model,
we have
mechanisms
intended
reflect
other
and
it to an
in
the
usage
as the
patterns
inclusion
and
implicit
and
as pro-
to mechanisms
maintenance
established of event
by
a
to support
importance
to lead
design
developed
the idea that
of equal
are also intended
help
adopt
ticm mechanisms,
event
and
invocation
They
characteristics
systems.
C++,
In addition
These
are
that
of implicit
A). We use this
for implicit
invocation
and Software Evolution
mechanisms.
requirements.
mediator-based
whenever
extending
existing
set of requirements
Integration
structure
(E, M, EM,
of a mechanism
analysis
have
event
underlying
of a four-tuple
design
Environment
that
of complex
explicit
declarations
invoca-
in component
interfaces. First, its
because
the events
specification
declared
as its
in component
it harder
out difficulties
owing
integrating
source
control any
designer the
readers
implicit
invocation
Many which
systems
fail
events; These
programming
events
this
arise
in FIELD,
which
to
should
requirement
Meyers
[25]
be
makes
has pointed
particularly
obviously
is
in
important
when
involved.
with
and
this
implicit
experiences
were
significantly Fourth,
constrain design. the designer should The available
with
events
the cannot can.
limits
not
primarily
be
able
[34], events
in
to other
to
specify
not be limited
that
include
the of use
freedom
to
cannot
be
LOOPS,
in
only
to abstract
relations
syntax
tree
to support
general
be faulted
in
that new
can
events
in which
cannot
indicate
allows
independent
designer’s
intended
so they
some of them
the
announce These
APPL/A
which
should
This
components
by limiting
invocation,
but
events.
it seems appropriate,
requirement.
events;
Gandalf,
systems
be explicit
can be passed
and when.
to declare
Limiting
design
to meet
announcement control
behaviors in this way eases reasoning invocation. It also gives the designer
be able
invocation
announce
event when
are announced
should
dimension,
signatures.
is that precisely
complicates
only variables [16].
are as important
signatures
events.
which
dependencies: components that in the same way as those that
armounce ncldes
over which component
of component
organize integrated
and
to satisfy
announced,
component use implicit
to use implicit
kind
are
requirement
tells
components. Clarifying about Components that Third,
Failure announce
problem,
that
announces
names
new tools.
related,
code. This
precise
event
that
to this
events
A second,
a component
interfaces.
to use components
urlderstanding when
that
methods,
these event
to those
this
limitations names
defined
and by the
GThe range of EM is a multiset because many implicit invocation mechanisms allow multiple copies of a method to be associated with an event, with each being invoked on announcement of the event. 7Signatures are appropriate in languages in which method signatures are also declared. ACM Transactions
on Software Engineering
and Methodology, Vol. 1, No. 3, July 1992.
244
.
system. the
K, J. Sullivan and D. Notkin Failure
same
denying
to
way the
meet
this
as restricting designer
full
the
requirement
the control
extensively
exploit
the systems A system
we have built. that fails to meet
ability
over
operations.
this
Smalltalk-80,
AP5,
requirement.
FIELD
events
In
events,
encoding
of arbitrary
Design
and
costly
in which
our
systems
nonstatic
the
set
event ified all
article,
in
Gandalf
kernel.
It
using
the
other
hand,
relational
expressions. event
to invoke action read and write
Smalltalk-80
parameters,
meet
predicates. defines
which
a
enables
model.
to implement
It should
take
implicit
no more
than
a
makes
broadens
it
easy
the range
Mechanisms
to use
our
we now discuss,
model,
we require
domains
for platforms
extends
that
approach
of application
other
than
of procedure examples and
C++
[33].8
each C++
object
be able to
hence our E consists of the collection of events exported by all a system. To a given event we want to be able to associfunctions member
multisets
of
sequential
defined
order.
methods
other
exported
member
functions
these
A
behaves
objects. by
returned.
using
Actual
standard
all
with
as follows.
associated with the event Event announcements
have
methods
by
functions
procedure
the methods
to the invoked
and
which
announcement
invoked
on our
can be applied.
member
announced,
on
efforts,
platforms,
of nonstatic
associates
events
one in any object-oriented language. The ease with can be implemented has significant benefits. It
of our formal
declare events, the objects in ate
FIELD, specified
by We
arbitrary
languages are feasible given the equivalent primary mechanism, used to implement the
in this
In terms
are
It is straightforward
based
approach
object-oriented pointers. Our
is the
much
invocation.
events that are used limits events to variable
regular
development
changing
of implicit
to declare
for unrestricted
implementation.
mechanisms
eliminates
use
in
events,
events.
day or two to implement which such mechanisms without
with
but allows
the
design
can announce
requirement
and
events
are specified
few fixed
invocation
AP5,
that
of components
defines about a dozen special-purpose routines. Another is LOOPS, which this
complicates
components
our EM
events
in
When
an
are executed should not
event
C++
Thus objects.
is
then
E.
Our
event
is
in an unspecreturn until
parameters
parameter
M
are
passing.
passed
One limita-
tion of the mechanism we describe here is that events do not support return values: signatures are not fully first class. Our design can be extended easily to fix this, if necessary. A critical decision in specifying an implicit invocation mechanism is deciding how
the
designer
specifies
EM.
We take
the
simplest
an object can register one of its member functions typed visible event. We require that the signatures
‘These we
systems
present
in
CommonLisp/CLOS ACM
TransactIons
were
actually
built
using
this
article.
The
program
a number
of minor
restructuring
route.
variations tool,
of the
described
Engineering
and Methodolo=q,
Vol. 1. No. 3, July
mechanism
later,
[3] implementation. on Software
At runtime
with any appropriately of events and associated
1992
used
a
Reconciling member
functions
furiction
m with
unregister
conform. event
methods,
on manipulation adopt, but manipulate tuples, method
In
terms
of EM
deletes
and Software Evolution
of our
model,
registering
(e, m) to EM.
tuples
from
EM.
as a set of tuples.
which we discuss in EM indirectly—using
key
Integration
e adds the tuple
which
for example. connections,
The
Environment
An
.
a member
We also allow Our
objects
mechanism
alternative
Section 6, is to allow high-level expressions
245
that
we do not
the programmer to that specify sets of
Nor does our mechanism support statically-bound although it would be desirable to do so.
to implementing
this
mechanism
is to
to
is based
design
event-
events
as C++
classes. instance
An object declares an event by including an event object as an variable in its public interface. An event object maintains a bag of
pointers exports
to member functions, to invoke when the event is announced, a method which is used to announce the event. When invoked
and (i.e.,
when the event is announced), this method simply iterates over the elements of the bag invoking the designated member functions. A complicating factor is that in C++ nonstatic member functions cannot be treated polymorphically lists and return types
(except appear
member
an implicit
functions
have
the class that declares the member functions unrelated maintain Rather,
bags of pointers so if their define
functions, implicitly
all
of the
invoked
parameter list first parameter
same
identical of type
is announced object
event
parameters.
actual
member member
types
appear
to
type.
store
this,
with
type
“pointer
to
For
each
to the member void’. A nonstatic
functions. functions
have
no implicit
to conform,
they
do conform.
bags
of pointers
nonstatic
a corresponding
static
member
static
function’s, member
to
member except function
this We
member
function function
to be with
a
for an additional is registered with
a pointer to the object in which to invoke the member to the corresponding static member function. When an
it invokes
the specified
argument,
static
objects
we define
an event by registering function and a pointer event
to nonstatic
declared
event
first
even if their declared parameter This problem is that nonstatic
function.” This makes the types of nonstatic in general. Thus, our event objects do not
we use the fact that
parameter; therefore
as uoid”s), to conform.
pointer
these
static
as the first The static
member
parameter
member
functions, followed
function
passing by the rest
casts the object
to each of the pointer
to a pointer of the type of the receiving object and invokes the nonstatic member function through this pointer, passing it the rest of the argument list. ]Ivent classes themselves export three methods. One implements event announcement. The signature event. The other two support ber function/object-pointer declare
and
implement
of this method defines the registration and unregistration
pairs, event
as described
classes
with
above.
event
signature of static
We use C++
signatures
of the mem-
macros
specified
to
by the
designer. This frees the designer from having to know about how events are actually announced and associated with methods. We also use C++ macros to reciuce the clutter required for the auxiliary static member functions, and to make it appear to the designer that nonstatic member functions are beimg registered directly with events. ACM
Transactions
on Software
Engineering
and Methodology,
Vol
1, No. 3. July
1992
246
.
K. J. Sullwan and D. Notkln
Extending
this
class could invoke
methods
C++
design
be defined
to meet
respecting
threads
order.
such
We have
are reasonably
not
confident
as
Presto
there
In
present
ways
we
especially tation
approach
common
of a shared
for solving
in
database
some common
to
of these
our
to model
as a collection that
key characteristics
encapsulation an example
4.1 Views
so that [11].
types
views,
each
or representations,
provides
In merging,
a different
separate
are selected and
can then fixed
of shared
view
interfaces
inductively
relationships.
our
idioms
sorts
while
visibility,
solutions
and
through
be used restriction
and composition An advantage
ease integration than
abstract
data
of a shared
are preserved,
based
by different
data rather
by
on interfaces types
(merged)
(ADTs)
representation
but multiple
implementa-
implementation that supports both the views relationships among them. A system kernel automatically using compatibility maps,
Different
set of compatibility
ened this
styles
and events;
of these
independence,
tools to operate on natural interfaces, up to support a range of tools. provides views for tools by merging
tions are replaced with a single and any necessary consistency produces merged implementations which
implicit
is the represen-
mediators
details. We present environment.
so.
for Tools
Tool-specific allowing conjured Garlan
such as component
of implementation extending the graph
and of design
We also present
in using
one example is avoiding unbounded circularities. We have developed idioms for meeting requirements retaining
but
in doing
mediator
a variety
of views.
use a
methods
enhancements,
problems
one example
arise
and to
could
registered
be no great
environments;
problems
method
invoke
which
can be used
to integrated
is easy. A new event
on the bag of methods
either
would
STYLES
section
[I]
implemented
that
DESIGN
this
order
The announcement
4. MEDIATOR-BASED
invocation-based
requirements
a partial
this
package
concurrently.
additional
to impose
on the
system’s
interfaces tools.
maps
by providing
rules [17]. of this approach
and
In
onto
Garlan’s
composition
approach,
a system
follow-on
language
it allows
of the basic
implementation
rules;
a programming is that
knowledge
a merged
merged
work
for defining
has
a
loosmaps
implementations
to
be optimized, with potentially significant savings in both time and space. For example, two views containing identical elements may share a single instance of that element in a merged view. On the other hand, the approach prevents types from being integrated simultaneously in several relationships: a view interface can be bound to only one merged implementation. Nor is merging desirable in all cases: protection or reuse concerns may suggest separate implementations, for example. Finally, in practice, generating merged implementations
ACM
Transactions
may
be costly,
on Software
since
Engineering
the
types
and
and Methodology,
relationships
Vol. 1, No
3, July
needed
1992
for
a
Reconciling broad
range
Environment
of environments
are
Integration not
and Software Evolution
likely
to be known
by the
.
247
system
in
advance. Our
design
approach
structure.
We have
as views
of a shared
map,
maintaining
Our
illustrates
presented graph.
G then
consistency
approach
reuses
a different
VS and
serves
among
existing
way
ES as tools, the
same
multiple
view
of achieving
but
views
they role
as a compatibility
of shared
implementations
a similar
can also be seen data.
by composing
them
using mediators. This obviates the need for merged implementations or for a system to generate such implementations. It also allows types to participate in multiple relationships simultaneously. Consider, for example, the way in which component Vfl can participate in both the G and C relationships. In the Garlan-style VS, ES, Our
and
approach,
a single
merged
N and the relationships
approach,
however,
views,
because
we stress
nents
independent.
does not naturally the
Thus
importance
we
are
instances of the identical elements are unacceptable, a hand-crafted However, more
in the
absence
allow for
consistent. alternative
of a clear
for optimization
of keeping
driven,
need
the components
be produced. the
of a set of
underlying
example,
to
keep
compomultiple
In cases where the costs of this is required in our approach.
for
optimization,
our
approach
is
flexible.
4L.2 Views The
type representing
G and C would
of Tools
converse
problem
representing A common as ADTs
is to provide
the states, solution
is to view
implemented
theory Our
at least, approach
ADTs
define
contrast, behcwioral ing events
functions, in terms
since ADT is similar,
abstractions
also include
integrated
views
and activities tools
as ADTs
of these
and to design
tool A13Ts. This
in terms explicitly
of method
exported
in
integrated
integration
relationships
Our solution to providing integrated views view tools as ABTs and to design integrated
views
is straightforward,
interfaces;
events.
views
tools.
composition is well understood. but is based on an extension of the notion
in
of ADT.
our abstractions,
We use the
type (ABT) to distinguish our components in the interface, ABTs model components
concretely participate independence.
of tools—single
of multiple
term
in
abstract
from ADTs. By includthat can abstractly and without
sacrificing
of a collection of tools, then, views as ABTs implemented
their is to on
top of these tools. Although we have not developed either a formal theory of ABT composition or even rules of thumb about how to apply this notion, our experiences may
with
be useful
this
approach
as a more
general
provide design
some evidence
that
ABT
composition
technique.
We illustrate the approach by extending G to implement a graph ABT in terms of VS and ES. The main problem in making this extension is to ensure that the event announcements of G reflect a graph abstraction. Specifically, viewing the sequence of event announcements of the underlying vertex and edge sets is not at all the same as viewing a sequence of event announcements that are natural to the graph. For example, a vertex deletion should be
ACM
Transactions
m Software
Enjgneering
and Methodology,
Vol. 1, No. 3, July
1992
248
.
K J. Sullivan and D. Notkln
G I
VS_lnserl(v)
[
VS_Delete(v)
Vs
I
ES
ES_lnsert(e)
[
Insert(v)
\
Delete(v)
Delete(e)
I
Member(v)
Member(e)
I
iterateo
1
Insert(e)
ES_Delete(e)
I
I ,
G_VS_lnsert(v)
[
‘f
Y
G_E$_lnean(e) G_ES_Deiete(e)
Figure
announced the
only
underlying
after
the incident
vertex
VS is visible.
the viewer
11
happens of the graph
which
abstraction
will
underlying
components, events
for
such those
as the
graph and
public
insertion
vate
methods update
and
events
methods
for
for
vertex
maintaining
vertex
components
components rather than the graph itself. A new version of G in which the sistent sequence of event announcements, in Fi~re tent view of Cl, is presented the
11.
are
temporarily
that is, the viewer of the graph will not be guaranteed relationship G always holds. It is important, however, to
announcing
there
since
nonexistent vertices; that the integration the
in which
from
is possible
view
allow
graph
even if the deletion
first,
see an inconsistent
continue
of the
I
edges are deleted,
set VS actually
Otherwise,
I
I
G_VS_Delete(v)
[
lterateo
edges
and
viewing
containing
edge the
sets,
to
underlying
viewers both see a conalso never see an inconsisThis
graph and
consistency
ABT
G
deletion of
VS
and
exports and
pri-
ES.
The
public methods are implemented as direct calls to corresponding methods in ES. G. VS–Delete( u), for example, simply calls VS. Delete(u). The VS and update methods implement the solution to the event announcement problem. The two update methods G. G–VS–Insert (u ) and G. G–ES–Delete( e ), are simple, announcing the events G. VS–Inserted(u) and G. ES–Deleted( e ), respectively.
ACM
TransactIons
The
other
on Software
update
Engmeermg
methods,
and Methodology,
G. G_ES_Insert(e
Vol. 1, No. 3, July
1992.
)
and
Reconciling G .G–VS–Delete(v),
Environment
maintain
consistency
G .G-VS-Delete(u),
for example,
first
ES
deletes
from
nounces
the
however,
each deletion
announces announce
vertex
edges
incident
deletion
G. Before
ES implicitly
a graph ABT ES. Components
249
events.
vertex
this
invokes
.
of a vertex
deleted
and
event
When
from
is
VS, it
then
G
an-
announced,
G. G-ES-Delete(e),
the edge deletion event of G as described the vertex deletion until after announcing
which
above. Thus, G does not deletion of all incident as a composition interested directly
of the in the
or edge sets are unaffected.
4.3 Abstract Chiron-1 tency
Depictions
[20] is characteristic
between
artists
internal
are used
another which
to maintain data
type.
a concrete
(i.e.,
graphical)
the
manager, In our
data
the
In
methods
and
explicitly
can be directly
[22].
Dot
type
example,
by
by
depictions
for
instance,
and
of a picture.
dot
defining
dots and
segment system,
from
P
with
of G and
a mediator
P. When
G, a corresponding
from
P. Likewise,
This
design
when
supports
both
dot
P changes, display
GP
a vertex or segment GP
and
updates
direct
that
graphical
that
exports into
stores
and
a graphic
such as InterViews graphics
as line
realizations,
maintains
or edge
new
to repre-
segments
graphical
G and
as filled
and
or
deleted
An
depiction
concrete
segments; these are the concrete depictions, abstract depictions, as in Chiron- 1. elements
and from
appropriate
P (for picture)
by a user interface
are drawn
abstract
to create
deleting
Each
the
and new mediators
a new component
for inserting displayed
invoked
segment
integrate
depiction
can be generated.
and
between
consis-
In Chiron-1,
is a representation
circles
We
graphics
the abstract
our
a representation
that
of the
1 system. this structure
G we define
events
maintain
an abstract
depiction
display
when
to represent artists.
between
abstract
that
of components.
that updates an abstract depiction when implicitly of an operation exported by the data type, and that
type
of the graph
from
An
a part of the Chironapproach, we model
components
systems
representations
consistency
arbitrary
updates
views
of user interface
and visual
artist is a component invoked by invocation
sent
of
announce
by deletion
on the
event
from
and
is invoked
edges. This design implements underlying set ABTs VS and vertex
Integration and Software Evolution
a bijection
is inserted
is inserted
into
G to restore
manipulation:
of
into
or
or deleted consistency.
when
any
tool
changes G, P is updated, and when a tool such as a mouse handler changes P, G is updated. P thus serves as an abstract depiction and GP as an artist. In contrast to Chiron-1, P and GP are undistinguished in our design, while abstract depictions and artists Both approaches have benefits.
are fixed Chiron-1
types used by all Chiron-1 instances. provides extensive support for user
interface development, including a rich abstract depiction language, a specialized version of Ada for implementing artists, and a mechanism implementing implicit invocation in a style similar to CLOS wrapper methods [3]. Our approach lacks these mechanisms but generalizes the technique, making it possible
to integrate
ACM
existing
Transactions
and new user interface
on Software
Engineering
systems
and Methodology,
more
flexibly.
Vol. 1, No. 3, July
1992.
250 4.4
K J Sullwan and D. Notkln
.
Compound
Relationships
Relationships part,
among
complex
as sets of simpler
provide
an
example,
vertices
in
G by further
and vertices useful
An idiom
of
of
dot-vertex dots
and
pair.
Each to
submediators This well
with idiom
those
diator
would
Integrating
Another into
key problem
new
tools;
equivalent most
do not
is, limiting and events
and dots
would
be
and
dot
can
sets plus
a
pairs. to maintain
for
each
deploy
by G
keep
an
corresponding
announced
to
indepen-
could
Similarly,
edges
in the
Chiron-
associated
might edge
1 system.
of submediators can be kept images
deploy locations
small,g
[23],
This
are needed.
in an image
a design
using
works
Although analy-
one subme-
be impractical.
Tools
The are
events
often
is to integrate
are limited
inadequate.
to allow
by which
designer
designers
possibilities
with
While
most
invocation
tools
can be made
obvious
choices:
required invariants; integration. There
the latter choice: by modifying the component that exports a sufficient
existing
by interfaces
explicit
the two
its usage to guarantee as needed to enable tight
to implement inside another
P
relationship
example,
events
incident
number
interfaces
the
for
equal.
of subartists
probably
these
export
other tools. This leaves
and
for environment
of method
vertex
dot-vertex) to
mediators
environments.
by existing
This
dot-vertex
GP,
in
a relationship
interfaces.
locations
millions-of-pixel
Existing
Such
dots
vertices.
use
of simple with
4.5
(for
respond
of their the
sis environment per pixel
DV
their
a “moderate”
implementations
sort.
in To
of corresponding
is to use submediators
vertices
mirrors
only
when
would keep
between
on the
this
of
between
consistent
useful
mediator
vertices
is moved. user
be expressed,
of the representations.
locations
on corresponding
relationships
a new
the
relationship
relationships
parts
relationships
that
as either
we have found
parts
our
intuitive
as a bijectivity
set of equality
instance
extend
equal
can frequently
among
requiring
constructing
be expressed
dent
we
remain
for
representations
relationships
tools
exported
tools
export
of tool
to interact to
use
the
functions, with
a tool
as
or to add methods are at least two ways
tool or by encapsulating interface implemented
it in
terms of the encapsulated tool. FIELD [27] takes the first approach; the Hewlett-Packard Encapsulator is a tool designed to facilitate the latter [10]. Our mediator approach does not dictate any of these choices, but facilitates integration once a choice is made. We have had several successes integrating existing
tools without
a user interface delete, and move
9In our C++ 25 bytes,
ACM
implementation
8 to reference
one to store
modification,
a boolean
Transactions
for example.
To illustrate,
we hypothesize
component D (for display) exporting methods graphic elements, but exporting no events.
the value
on Software
a mediator two
integers,
to limit
to keep
two
the propagation
Engineering
integer-maintaining
16 to register
with
each
classes
of their
changed
of updates,
and Methodology,
Vol.
1, No. 3, July
1992
to
insert,
equal
requires
events,
and
Reconciling
We integrate or deleting
P and
graphics
and deletion
Environment D through
into
This
D upon
of dots and segments
is sufficient
to maintain
because
into
and Software Evolutlon PD that
being
so that
than
PD
D does not announce
that
updates of P. We used this design in integrating InterViews with our graph ABT G. To complete
the
system
we defined
We handle
mouse
clicks
frolm
P (since
we cannot
change
D directly).
edly
moving
VS and “existing”
update
interface
in integrating
a program
toolkit
could
without
design
both tightly
This
system
is
to a vertex
in
integrates
an
used
graph
described
to or
by repeat-
Griswold
dependence
on
a mouse
elements
dragging
modification.
program
tool.
thus
is
based
to handle
or deleting
We handle
of D and
restriction
interface
H
each dot
be used to trigger
a user
by adding
This
an existing
restructuring
This
of a dot is reflected
to D by submediators.
user
approach into
a dot in P. Each
back
elements
D.
a component
device.
by addition
a dot or segment
between changes
events
input
D by inserting
invoked
whenever
251
.
P. We also integrate
a correspondence other
updates
implicitly
or from
submediators,
as no component
necessary
a mediator
or from
or segment with D, using moves, D is updated. P as long
Integration
this
component in
the
next
section. 4.6
Miscellaneous
In this and
section,
idioms
following tions,
we discuss
that definition
are
a number
common shows
and the implementation
the
and
of mediator useful.
instance
implementation
We use variables,
of one of these
update
GP
strategies
as an example.
update
method
methods
The
declara-
in C++.
class GP { / * lJpDATE METHODS *\ void WhenVertexDeleted(Vetlex & v); void WhenVertexAdded(Vertex & v); void WhenEdgeDeleted( Edge & e), void WhenEdgeAdded(Edge & e); void When DotDeleted(Dot & d); void When DotAdded(Dot & d); void WhenSegmentl>eleted( Segment & s); void WhenSegmentAdded(Seg merit & s); /“ INSTANCE VARIABLES *\ G* graph; P* picture; Boolean VertexDotInterlock; Boolean EdgeSegmentInterlock; Binary Relation VertexToDot; Binary Relation DotToVertex; Binary Relation EdgeToSegment; Binary Relation SegmentToEdge; }; void GP: :WhenSegmentAdded(Segment { if (ESlnterlock = false) { ACM
Transactions
on Software
& s)
Engineering
and Methodology,
Vol. 1, No. 3, July
19%3.
252
K. J. Sullivan and D, Notkin
.
ESlnterlock = true; Vertex+ VI = new Vertex(s.Orig,X, s.Ong.Y); Vertex’ V2 = new Vertex(s.Dest X, s.Dest Y): Edge & e = *new Edge(’vi, ‘v2); EdgeToSegment InsertPair(e, s); SegmentToEdge.lnsertPair(s, e); graph ~ ES _lnsert(e); ESlnterlock = false; } } Avoiding ponents
In general,
circularities. participating
allowing
in a relationship
updates
requires
to either
ensuring
that
of two
circular
compropa-
gation makes
of updates is avoided. The mutual update dependence of G and P this necessary. For instance, if G changes P is updated, but this
should
not necessarily
One common mediators.
structure
In
variables
our
GP,
edges
are needed requires
for
again.
in this
is to add interlocks we use
two
one is sufficient.
one is used
segments;
the other
and dots.
design
because
addition
of an edge to G, which
of a segment
may
in turn
the addition of vertices to G, and hence of dots to P. Thus the first P may require the propagation of additional updates back to P. Consider
adding
mentAdded(s of GP. This incident
to P, which
method
sets the
are then
added
to the
implicitly
vertex
invoke
G,
since
implicitly
this
event
This
the
vertex-dot
set
of
G. The
but
is now
the
set.
to
GP. WhenSeg-
in the
above
resulting
definition
vertex
v ). Since
Finally,
edge-segment
the
insertion vertex-dot
an edge
interlock
dots are
is added
is already
to
set, so
is dismissed.
design
will
not work
in the presence
of concurrency.
is that updates having both local and nonlocal appears that a general solution compatible nested transaction mechanism [26], although The
change
sets it and then adds corresponding but these events invokes GP again,
interlock
GP;
invoking
invokes
is given
GP. When VertexAdded(
interlock is not yet set, this method to P. Each dot addition implicitly ignored
implicitly
of which
to
require
segment-edge interlock and then adds an edge, the consistency of G, these to G. 10 To maintain
on two new vertices,
vertices events
a segment
), the implementation
to the
boolean-valued
Here,
and corresponding
vertices
addition
this
instance,
designs,
involving
cycles involving
interlocks
P, for example,
of
In many
circularities
is used to break
G to be updated
we use to overcome
design
as interlocks.
to break Two
cause
design
consequence
of GP of our
also
seems
approach,
complex.
but
of the
One key problem
effects need to be serialized. with our approach requires we have not verified this.
However,
this
requirement
dependence between G and P. A similar interlock-based be necessary under the hardwired and event approaches
complexity for
is not
a mutual
approach discussed
It a a
update
would also in Section
— 10A more useful sponding or both ACM
implementation
to the endpoints vertices
Transactions
would
would
of the new
be mstantlated,
on Software
define
segment.
Engineering
GP
to look
If found,
for vertices
these
vertices
m
G at locations
would
be used;
as necessary. and Methodology.
Vol.
1, No. 3, July
1992
corre-
if not,
one
Reconciling 2. Of the approaches this
complexity:
visible, tools
with
G and
stand
the
That
Integration and Software Evolution
only the encapsulation-based
mutual
G and
Implementing P. It is true, of the
presented,
the
hiding
Environment
dependence
P entirely.
P more
This,
is
avoided
in turn,
approach
by
makes
making
of G and
types
need
P. However,
not
the
be known
as a composition
by
GP
invocations
the events of these
rather
components,
than
which
of ABTs.
implicit
might
more
make
details
implementor ES
of
GP.
can be ignored
by
On the other
accurately
reasoning
G and under-
implementation
the
of VS and
in the specifications
explicit
GP
of other
of both must
clients of G, such as GP. Reasoning in terms of ABTs and ABT may be more complex than in terms of ADTs, owing to the implicit
avoids
difficult.
specifications
G is implemented
253
only
integration
GP seems to require a deep understanding and reasonable, that the implementor of
underlying
.
hand,
models
easier,
interactions inclusion of making
the behavior
not harder.
Externalized relations. We make extensive use of separate components to track relations among independent components. GP, for example, uses its instance variable DotToVertex to track the association between dots and vertices:
given
a dot,
it
returns
the
associated
vertex.
Rumbaugh
discuss a number of advantages of externalized representations in contrast to representations based on embedded pointers [29]. l?rom they
our
perspective,
support
integration
can be viewed that
define
includes
externalized
as externalized the
a pair
relations
of independent associationsll
semantics
of the
of pointers,
have
two
components. with
association.
for example,
advantages.
Mediators
implicitly The
et
First,
themselves
invoked
methods
implementation
one to G and
al.
of relations,
of
one to P. This
GP
is an
externalized representation of the association between these components. Second, efficiently implemented relations enable more efficient integration. For
example,
method number incident
we can improve
the
performance
0( IES 1)in space, to represent the relation pe~ event announced by ES to keep these 5. APPLICATIONS We have based noting
of the vertex-deletion
update
of G by an order of magnitude—from 0(1 ESI) to 0(] ES( u) I), the of edges incident on -by replacing the exhaustive search of ES for edges with a lookup in a hash table keyed by vertex. The cost is
a number
of medium-scale
systemslz
approach. In this section, we briefly where our approach was most useful.
Computer-Aided
time
AND EXPERIENCES
developed
design places
and its inverse, and constant relations up to date.
Geometric
Design
(CAGD).
using
describe
McCabe
our mediatorthese
systems,
developed
a proto-
type CAGD [24] kernel that extends our graph environment. This environment supports editing of a mesh, a representation of surface (technically, a two-manifold) in an n-dimensional Euclidean space. A mesh is similar
11We use the terms assoczatzon to denote a tuple and relation a set of tuples, 12The systems we describe range in size from ten to thirty thousand lines of code ACM
Transactions
on Software
Engineering
and Methodology,
Vol. 1, No. 3, July
1992.
254
K. J Suliwan and D. Notkin
.
to a graph,
but
edges around This
also
maintains in this
supports
in
view,
for
with
n-dimensional
one
a mesh
multiple
in VS have ES
relations
property stores
over
topological They
cal property,
by operating
tool
such set
ABT
views
to create
on ES;
As a vertex
the
motion.
is
This
be viewed
as vertex
of edges
a mesh
geometrical
one
of
as
a
set VS and an edge set ES. Vertices
algebra—a
and
allow
animate (n > 2) to
information
set. 13 A4 implements
are
ordering
of a mesh.
views
geometry
storing
a topological
this
information—the
views
other
projections. as a vertex
lists
and ES. Separate useful.
graphical
example,
collection of two-dimensional A mesh, M, is represented labels.
topological
case.
system
dragged allows
it
vertices,
and
geometry several
and
ordering
as a composition
an integrated
a torus
another
plus
mesh
or a sphere,
to assign
VS
of
view
a topologi-
a geometric
layout
by
operating on VS; and a third to compute a smooth surface or a projection the mesh by operating on M. For example, McCabe defined a mediator that projects n-dimensional meshes
into
Another serve
two-dimensional
subspaces,
mediator
composes
as abstract
depictions.
A third to keep
sistent.
from
the
mapping
tion, the reverse mapping of the general ambiguity
two-dimensional
implementing
n and
plane.
abstract
The tent
restructuring. tool, which
key
the
the
engineer
system
13ES implements
represents
the
fill to
in the missing information n-dimensional movements provide
policies
of this
program to indicate
updates
a quad-edge
manifolds
vertices discards
TransactIons
con-
informa-
for
a convenient
any
given
by mapparallel to
framework
instance
of the
over any ambiguity.
system
without
tool
to
is
be
local
to compensate
the
maintenance A
restructured.
for ambithat
changes for
and such
provides changes.
of two
consis-
syntactic
view
representations A semantic
on Software
view
data structure [ 15]. This is not perfect for a CAGD system; it only however, makes it useful for our boundary. Its clean structure,
work. ACM
a
Griswold applied our approach in his program allows an engineer to restructure a software system
design
of
the
that with
its meaning, in preparation for making functional enhanceformal parameters in a procedure declaration are swapped, system compensates by swapping actual parameters at all this would change the meaning of the program.
views
allows that
to
depictions
dimensions
guity problem. This approach increases flexibility constrains designers by fixing a policy for handling
while preserving ments [ 14]. If the for example, the call sites, unless
unchanged.
components
two-dimensional
n to two
Mediators
designer-defined
Program restructuring
topology with
from two to n is ambiguous. This is an instance problem for systems supporting views. McCabe
solved this with mediators that ping two-dimensional movements the
their
meshes
composes
display based on InterViews. McCabe used submediators Because
leaving
two-dimensional
of
Engmeermg
and Methodology,
Vol. 1, No
3, July
1992
Reconciling
Environment
Integration
and Software Evolution
255
.
H allows ing
the
and
system
to find
meaning
to determine
all
aspects
in the face of a local
Figure
12 shows
tool;
AST
PDG
the
RELS
the
the
representation
is a mediator
consistent. MED employs 10,000
lines
without
code,
includes
RELS.
because
computation
of program
trees
expensive,15
and
beginning the
of
AST
supporting
views:
implementing from
slippage
Parallel
each
processor
‘I’he
The
phase
is a parallel
l~Griswold’s article,
supports and
sequential
event
mechanism,
uses CLOS
complexity
PDG
it allowed
integrated of AST
over almost
and
PDG,
relations
from
syntax
only
changes
a general
issue
to allow
slippage
provide
a convenient
in
Third,
abstract
is required caches
and
and
representation.
graphs
the
tree; graph;
nodes;
AST
of these
program
applied
for
at
the
made
to
systems
in the consistency
required
of
framework
implemention
for details
wrapper
is not known, ACM Transactions
a program language.
are
graphs,
but
tools
based.
an earlier
to announce
is thought
design
of a
on an interconnected a sequential
is represented
version
tool,
tool
of the
pro-
programs
The process fourth
of
system
as
used to
provides
a
specified
in
events.
to be roughly Engineering
manipulating
depicting The
process
as a collection
for
graphical,
is text
on Software
runs
respectively.
implements
methods
in the
executes
interactive
tools
programs,
approach
that
in a graph
four
which
our
nonshared-memory parallel computsystem is a sequential composition of
program
graph
and interconnection
simple
15The
We also
and each processor
environment
flowcharts
this
phase
graph;
view
MED
isolating
syntax
involved.
given phase. Concretely, in the C++ programming
grams. write
for
be
use
illustrates
environment for programming Abstractly, a program in this
phases, in any objects
This
restructuring
PDG
First,
to
consistency
Mediators
programming.
prototype ers [30].
semantic
operation,
and
idioms. PDG,
extensive
it is ofken beneficial
the components
and
keeping
an integrated
PDG
restructuring.
representations.
mean-
to restore
dependence
AST
dependence
since
a restructuring
during
multiple
and
is the abstract
while
mediator
makes
between
REST on an
between
it provides
mapping is
preserves
to be changed
a program
comprising
REST
syntactic
on
RELS
interesting
change. 14 Second,
which
system.
based
maintains
existing
have
based
relations
that
several
of
of the
representation
a set of externalized
MED
a transformation that
change.
structure
syntactic
semantic
whether
of a program
cubic
in the
and Methodology,
size of the program. Vol. 1, No. 3, July
1992.
256
.
user
K, J. Sullivan and D. Notkin
interface
that
allows
instances
of the
deleted dynamically. The phase, graph,
and process
tools
a program
database
by mediators
that
consistent.
Furthermore,
mutually related
to each
changed,
all graphs
accordingly; This their
respective
updates
then
of the
them
by
and the
parts name
that
execute
of the that
been
are also is
are updated
to develop
the
Once the tools
and
developed
to keep
of
tools.
on them.
had
mediators
parts
process
process
independently
operate
and
database
database
of a sequential
to all graph
databases
adding
respective
three
that
to be created
to their
designers
and the tools
tools
the depictions
If the
propagate
separate
parts
integrated
keep
processors
allowed
of the database
are related
the
by mediators. having
these
structure
parts we
other
other
related
and
tested,
representations
consistent. 6. RELATED WORK: IMPLICIT INVOCATION Our
research
Many
has
helped
have contributed
use.
Our
useful
research
in turn
has
in analyzing
existing
implicit
section
by
discusses cover
us understand
to the nature
system,
taking
systems
many
and
produced
related
to our
in
that
the
use of mediators.
we have
we found
We organize
next
The
invocation
of systems.
mechanism
mechanisms.
approach
in implicit
a range
invocation
a framework
invocation
a similar
of the key issues
evaluate
of the implicit
section,
systems
this which
we discuss
and mediators,
and they
seem to be representative of the many important systems that we omit. In this section we analyze four implicit invocation mechanisms in terms
of
the
It
model
helps
presented
to validate
similarity
in Section
our
among
model
these
systems
[13].
analysis
by showing
of a set of seemingly
capabilities supported model or implemented explore
3. This
that
serves it
diverse
several
captures
purposes.
a key
mechanisms.
underlying
It also highlights
by some mechanisms that are not captured by our by our mechanism. A more recent effort uses Z [31] to
dimensions
based
on a formal
description
of implicit
invocation
As we discussed in Section 3, we characterize implicit invocation isms in terms of a set E of events, each of which can be announced, of methods,
each
of which
can be invoked;
a mapping
EM;
mechana set M
E -2
M from
A that invokes all the methods associated with a given event whenever that event is announced. In the analysis of related mechanisms, we focus on three events
to
issues:
the
between dure
multi
sets
manner
events
and
of
in
methods;
which
methods;
A; and restrictions,
and
the the
no further) not strictly
attribute grammar and to detect cyclic
system may dependencies
16In most such systems,
ES
ACM
associations
TransactIons
is represented
are represented
on Software
user
behavior
if any, imposed
We note here (and discuss representations for purposes
at run-time,
an
Engineering
event
announcement
manipulates of the
procedure
the
event
on E, M, and
association
announcement
EM proce-
EM.
that some mechanisms use their related to implicit invocation. An
attribute evaluation use its EM to optimize among attributes. 16 FIELD queries its EM
exphcitly as direct
only links
and Methodology,
during between Vol.
attribute tree
grammar
nodes.
1, No. 3, July
1992
processing;
Reconciling to avoid
spawning
used to support
Environment
redundant debugging
announcement
Integration
copies
of network
by indicating
of a given
and Software Evolution tools.
which
An
methods
EM
.
could
would
257 also be
be invoked
by
event.
6.1 LOOPS LOOPS [32] extends LISP with active valz~es, to support access-oriented programming. An active value av is an object used to annotate a variable v. Such an annotation causes each access to v to be replaced by invocation of a method exported by au. Specifically, reading u invokes au. Get WrappedValue( ), and writing the value x into v invokes au. Put WrappedValue( x ). The base active
value
ods that
mimic
objects.
Subclass
We
model
events tributes
this
The user thus both
as follows.
manipulates object
the
On the other or mechanism:
EM
This
components
state
for those
meth-
of active
value
for additional
variable
behaviors.
u contributes
two
it from
v adds
of fixed
pairs
to or deletes
from
that
value
announce read
of tuples
specified
annotation
object.
LOOPS
events—to
variables—and
in also the
written.
and
hand, LOOPS supports a capability not captured by our model the programmer can specify an order on the set of methods
with
an
suggests
event.
a possible
be allowed
to specify
given event. The imported by many order,
methods Each
in terms
and an active
This
annotations. When a variable activated; when these access may be implicitly invoked. could
the local
U.read( ) and u.writterz( x). Each active value au conto M, av.Get WrappedValue{ ) and au. Put Wrapped-
can be announced—to
associated
these
au to v or detaching
of a variable that
specialize
implementations using
~ o .GetWrappedValue( ) ~ o. WrappedValue (x).
~.reado u.written(x)
events
default
and writes
mechanism
to 1?, namely two methods
restricts
defines
reads
designers
Vatue( x ). Attaching EM the maplets17
terms
class
variable
a complete
is
accomplished
is accessed, their instance
extension a partial
of our order
by
nesting
active
value
active values attached to it are variables, nested active values model
and
mechanism:
on the methods
the
associated
user
with
a
ordering issue arises naturally, since an event may be components simultaneously. A partial order allows for no order,
or a properly
partial
order.
6.2 APPLIA APPL/A [34] is ming. APPL/A’s
an Ada-based language that supports process programimplicit invocation mechanism focuses on a relational
model.
imposes
APPL/A
relations,
instances
the events that update, and find.
17By maplet
restrictions
of a special relations
can
we mean a single tuple
ACM Transactions
type
similar
to
constructor,
announce
are
(e, m) in the overall
on Software Engineering
those
of
can announce restricted
mapping
EM
to
LOOPS.
Only
events, insert,
and
delete,
of events to methods.
and Methodology, Vol 1, No 3, July 1992.
258
.
K. J. Sullwan and D, Notkln
These
restrictions
imply
invocation mechanisms model those components potential
benefits
that
to
the
programmer
of implicit
invocation,
such
all components are modeled as relations, forego more natural representations in best. APPL\A,
in contrast
must
either
use
connect components that are not If explicit invocation as relations.
to our
as easier
explicit
relations, is used,
evolution,
are lost.
then the programmer may situations where relations
mechanism,
handles
or the
concurrency
If
have to are not
by allowing
the designer to specify the synchronization of event announcement with the execution of invoked methods. APPL/A also allows a component that receives multiple events to prioritize these events. Events nent, which handles them in priority order. 6.3
are queued
at the
compo-
invocation mechanism in of other objects [21]. 18 All
which objects
objects in this
Smalltalk-80
Smalltalk-80 defines an implicit register themselves as dependents system
export
one object
three
predefine
x registers
with
events
another
and three
object
associated with the corresponding Specifically, the method update
events With(s,
With(s,
) is associated
p) event,
updateRequest(s
predefine
methods.
y the predefine
methods
of x. p ) is associated with
with
the
changeRequest(
When of y are
changeds), and
perform Updaters, p) is associated with broadcast With(s, p). The event parameter s is a Smalltalk-80 symbol, a literal value, and p is an arbitrary object. ChangeWith(s, cal views,
that
p) is announced the announcing
update
themselves
request
permission
implicitly
to restore from
invoked
to notify object,
consistency.
registered
return
registered
a model,
true
objects,
ChangeRequest(s)
objects
or false
to
usually
has changed.
to make
Views
is announced
a change.
indicate
graphican then
whether
The
to
methods
permission
is
granted or not. These answers are conjoined and the result returned to the event announcer. This can be used to implement cooperation among components that do not know about each other. Broadcast With(s, p ) invokes, in each registered object, the method named by s with parameter p. In terms of our model, an object x contributes its three predefine to E and its three methods to M. Registering x with, from, y, respectively, adds to or deletes from EM
events
or unregistrating it the following three
maplets:lg x. changedWith(s, p) x. changeRequest (s) x. broadcast(s, p)
18While
this
aggressively 19Actually, forms both
change
-
y.update(s, p) y.updateRequest(s) y.s(p),
dependence
mechanism
is
available
for
other
reasons,
it
there
of those
are eight described
a symbol
and
an
events
with
above.
There
object
as
corresponding are three
parameters;
methods.
The
for change
notification,
one
just
takes
additional
events
for example,
a symbol:
and
parameters. ACM
is
used
most
in MVC.
Transactions
on Software
Engineering
and Methodology.
Vol. 1, No. 3, July
1992
one
are short One takes takes
no
Reconciling In this
system
explicit
the user
registration,
rived. tional
an
to
the
maplets,
broadcast
Integration and Software Evolution
manipulates
an object
Specifically,
responding
Environment
object
EM
dependence
changed
With
and
one for each possible The
event.
indirectly
dependence
In part, ming
this
invocation. of
the
that
Second,
suggests
that
value
announcement
several
versions
values
values
of these
of the parameter
in
A
is de-
EM
cor-
plus
addi-
s passed
to the
invokes
methods
extensions to our model and EM indirectly, in terms of
but
it also implements
analogy
between
changeRequest
from
an implicit
by
mechanism
defined events,
the
explicit
computes
invocation
implicitly
but
this
by using
a programand implicit a return
requires
invoked
only
value
synthesis
methods.
events,
visible, leaving mechanisms
and cannot
system-defined
can be encoded
solution
a parameter
problem occurs superclass and
the system-defined
can leave them information-hiding
is that
by the designer
is not
designer-defined events the difficulty of reasoning
new events
on interfaces
our
returned
of this Events
code reuse. The exported by the hide
of simplicity,
the way in which
One reason is that interfaces, increasing defining
maplets events,
procedure
through EM
The
mechanism defines the semantics of this operation for the event as Boolean conjunction. General support for return seem to require that the designer be able to specify such
A limitation announced.
sake
emphasizes
returning
Smalltalk-80 changeRequest values would procedures.
two
which
259
can be useful. In contrast to the mechanisms disours is based on direct, low-level manipulation of EM.
is for the
abstraction
from
changeRequest
sequentially in an unspecified order. The Smalltalk-80 mechanism suggests two perhaps to our mechanism. First, specifying another representation, cussed in this article,
by specifying,
relation implies
.
events
completely
satisfactory
conflicts
with
class inheritance
case it cannot
superclass events such as private
be used to hide
.20
do not appear in component about events. More seriously,
when a subclass needs both to hide also to export its own events. Either in which
are
as parameterized
selected
export
for events it can
its own,
visible. The problem subclasses in C++ parameterizations
or it
is that operate of events
or methods. 6.4
FIELD
FIELD [27] defines selective broadcast
an integration mechanism of ASCII messages on
implicit
abstractions
invocation
communication
mechanism,
can
although
be implemented the indirect
cation is of most interest to this analysis. Each FIELD tool exports a method interface to which it the method
can respond. name and
A message parameters.
for Unix-hosted tools based on a network. Both explicit and on
by defining
is an ASCII string Tools can invoke
‘o Of course, Smalltalk-80 makes it easy to define classes and methods but in practice such modifications are not common. ACM Transactions
on Software
Engineering
top
connection
and Methodology,
of this
of implicit
basic invo-
a set of messages that other
encodes both tools, either
representing
new events,
Vol. 1, No. 3, July
1992.
260
K J. Sullwan and D. Notkin
.
explicitly or implicitly—the the mechanism—by sending message server, which routes Routing is based on a set of An
expression
are
written
cation the
consists as
message, (ASCII)
a method methods
of
regular it
distinction messages invocations expressions
a pattern
part
expressions.
finds
message
all
is only in the designer’s use of to a distinguished tool called the to their destinations. registered by tools with the server. and
When
an
the
action
server
expressions for which Each corresponding
string.
to be called in the tool that are then invoked. A pattern
part.
Patterns
receives
an
the pattern action part
invo-
matches specifies
registered the expression. All that literally names a specific
such tool
and method supports explicit invocation, since invokers must name the tool and the method to invoke. Other patterns can be used to specify events or classes of events. a set of methods {m,} to In terms of our model, a FIELD tool t contributes M.
E
corresponds
announce in terms from
to
an event
the
infinite
by sending
set
of ASCII
an arbitrary
of a set T of pattern-method
strings,
string.
pairs
{(p,
p
specifies
EM m)}.
since
a tool
is specified EM
can
indirectly
is then
computed
T as necessary.
Specifically, that
each
is true
effect
regular
expression
p) = {e ● E Imatches(
Euents(
events,
if and
of adding
only
(p,
if event
p, e)},
e is recognized
m) to or deleting
it from
an
where by
equivalence
matches regular
T is to add
is
class
of
a predicate p. The
expression to or delete
EM
from
the set of maplets {e Thus
EM,
associated ously,
too, with
EM
procedure ally,
can
infinite,
a method
is not A
be
thus
an
(p)}. infinite
of a single
as an infinite
EM(e)
of methods
supports
Euent.s
since
when
EM(e)
{ml(p, m) FIELD
E
by insertion
represented
calculates
the multiset
nzle
set. Rather,
the
event
invoked
event
e is
of events
(p,
can
the
be
T. Obvi-
m,) into
announcement
announced.
Specific-
by e is
G T A matclzes(p,
a declarative
class pair
e)}.
specification
mechanism
based
on
regular expressions. Our approach, in contrast, lacks the equivalent of T and a mapping from T to EM, Instead, our design is intended to support a more imperative style of programming with implicit invocation. We do not yet fully understand the tradeoffs involved in these respective choices. FIELD also supports concurrent and asynchronous invocation. The FIELD announcement
procedure
A invokes
methods
concurrently
in an unspecified
order. An event announcer specifies whether the event is synchronous or asynchronous. Asynchronous events return immediately with no return value. Synchronous announcements return after all methods return, returning the string value returned by the fh-st method to terminate. This suggests possible extensions to our mechanism. A concurrent mechanism encapsulating the complexities of thread creation, dispatching, and synchronization ACM
Transactions
may on Software
provide Engineering
‘significant
benefits
and Methodology,
Vol.
at
a
reasonable
1, No. 3, July
1992
cost.
Reconciling However,
we
invocation
with
have
Environment
no
Integration and Software Evolution
systematic
approach
to
combining
.
261
asynchronous
mediators.
6.5 AP5 AP5
[7] extends
mechanism
Common
based
on
Lisp
triggers
with
a relational
to support
database
declarative,
abstraction
and
constraint-based
a
pro-
t = (p, m) has a predicate part p and an action gramming. An AP5 trigger part m. A predicate is written in a notation based on first-order logic, extended with relational operators, and a temporal aspect capturing the notions of before and after a proposed transaction. When a transaction is proposed,
the
system
corresponding
action
constraint, actions
a predicate were
project
the
corresponding transaction
to implement
arbitrary
if and
only
relational
that
action
activities,
occur part
or simply
and
to true.
would
such
if proposed
then
aborts
invokes
the
To maintain either
a
transmodifies
it. Action
parts
as sending
mail
can to a
if the
is the infinite set of proposed changes to a an AP5 predicate p specifies a set of events p )}, where satisfies is a predicate that is true
application
predicate
change
p. T’bus,
e would
cause
the
database
t = (p, m) contributes
a trigger
to satisfy
m to M and, to
the set of maplets {e ~ mlsatisfies(e,
The
predicates
evaluate
manager.
In terms of our model, E database. Much as in FIELD, Euents( p) = {e ● E Isatisftes(e,
EM,
all
that
violations
the proposed
be used
reevaluates
of those
detects
to commit;
and resubmits also
logically parts
AP5
announcement
procedure
p)}.
A invokes
the
event in an unspecified sequential order. A key advantage of AP5 is its support for atomic to guarantee
global
that
transactions
way
for
rency nested
that control
to solve the consistency
environments.
our imperative
Although
approach
by implementing
tools
we
can exploit and mediators
triggered
transactions,
in the face of concurrent
are necessary
concurrent
appears
consistency
methods
which
updates. problem
have
not
it uses
We believe in a general
verified
this,
transaction-based on a platform
by an
it
concursupporting
transactions.
7. RELATED WORK: MEDIATORS Our emphasis on the separate specification, relationships among components is based, numerous section, ~upport control,
related
efforts
that
suggests
the
design, and implementation in part, on evidence produced utility
of this
approach.
of by
In this
we discuss a number of these systems. Many of these systems provide in areas unrelated to our focus—obj ect management and user access for example. Because our work applies narrowly to integration and
evolution, we omit systems address. ACM
discussion
TransactIons
of these
on Software
and other
Engineering
important
and Methodology.
issues
that
these
Vol. 1, No. 3, July
1992
262 7.1
K. J Sulllvan and D Notkin
.
Unix Pipes such as Is, awk, grep, and sort are independent pipes [28]. This ease of integration derives
Most Unix programs, to integrate using separation
of tool
and integration
nism
for recombining
pipes
also encourages
concerns,
the two. their
Unix
combined
shells
that
use. We view
with
allow
Unix
a flexible
the user
programs
that relate them. (Viewing pipes as simple as complex mediators is also reasonable.)
Although
this
sequences tive
approach
of tools,
makes
it makes
environments.
The
it easy to assemble
it hard
to implement
key reason
is that
only
and pipes
tools
systems
tightly
and
Unix
by composing
integrated,
one-way
mecha-
easy access to
as tools,
as mediators programs
but easy from the
stream
interac-
composition
relationships are supported. In addition, common practice in Unix limits programs to a single input (stdin,) and two output (stdout and stderr) streams to which
pipes
mutual tured
7.2
can
information
Forest
costly,
with
message
program
message
to the
Policy
each
can
evaluated
tool
make
make
sharing
has
to linearize
are
in
it hard
to implement
of fine-grained,
FIELD,
Forest,
and
struc-
parse
data.
event;
guage
in
they
written
which that
they
able
approach
7.3
Contracts
as
sets
of
If none
evaluate
an
a tool,
send
another
in tools
true
quite
interpreted
in terms
of interfaces
that
no action
On
the
language
are
is taken,
is executed.
Each
is
components;
limited.
bound
and other
hand,
may
to
the
a
lanthey
be a reason-
fly.
for specifying declarations
Conditions functions,
expression
tool)
is
conformance
to true,
mediators.
an
on the
pairs.
load. The conditions
system
(Unix
and
conditions maintained; invariant.
is not
to be executed,
environment-defined
the
specified
a language
to
condition-action
and
returns
first-class
written
to integrating
et al. define
contracts
are
mediators
program
message
variables
written.
not
pattern-acpart
or do nothing.
), which
are
register
an action
a policy
but
the action associated with the first as limited programs can be viewed
single
tools
however,
an invocation
over
order
As
In
to a tool,
server,
expressions
in the
otherwise Policy
suggest
send
message
LoadAverage(
as
server.
to be sent
programs
Boolean
such
behavioral
relationships
[ 18]. A contract
participating
components
specifies must
based
on
a relationexport;
pre-
on and initialization of these components; an invariant to be and mutual invocation obligations sufficient to maintain the To encourage the identification of generally useful relationships,
contracts are generic with respect declarations specify how particular roles specified by a contract. ACM
restrictions
and
of FIELD.
a message
A policy
ship
tools
since
[12] is an extension
pairs
invocation
Helm
These
among
Forest
tion
are
be associated.
dependencies
Transactions
on Software
Engmeermg
to participating components
and Methodology.
components. discharge the
Vol.
1. No. 3, July
Conformance obligations of
1992
Reconciling This
work
provides
be treated
additional
as first-class
approach First,
Environment
we define contracts
Integration and Software Evolution
evidence
entities
differs
in
that
significantly
specify
policies
behavioral
software
that
263
relationships
systems.
from
in terms
.
We
should
agree;
but
the
of contracts.
of explicit
invocation
obligations,
While this does not preclude rate components, it is biased
the design of behavioral relationships as sepatowards hard-wired designs. Our approach is to
state
in a way
invariants
adoption to adopt
and
policies
of a mediator-based hard-wired or other
Second,
contracts
design, approaches
emphasize
and is not localized
hand,
contracts
“behavioral
does not bias
over
compositions.
Third,
our
by the
[ ibid.,
observation
. . are spread
approach
invariants
in
is tailored
the
7.4 ThingLab Constraint ming
the designer dictate.
free
(classes
in
that
across
many
use with be
On the other languages,
class definitions” the
equal
existing
as opposed
cannot
p. 178]. in previous
[ ibid.,
importance
languages.
We iso-
to language-level,
represented
easily
of
because
in
imperative
II and OPUS programming
tionships
for
specification,
these declarative constructs programming frameworks.
eases
the components
p. 169]. Our approach, in contrast, emphasizes relationships and the components they relate. late
This
et al. state that “the specification of a of contracts and conformance declara-
to one class definition”
are justified
design.
but also leaves as circumstances
relationships
this system) that they relate. Helm class becomes spread over a number tions,
that
among
systems
is based
otherwise
emphasize
precisely
independent language
on separate
specification
components.
support
for
Constraint
the
declarative
of relaprogram-
assertion
of
constraints. Many
systems,
including
ThingLab
II
[8],
a successor
to ThingLab
and OPUS [19] are based on a set of variables—components from some domain—and a set of constraints relating these the value
of a variable
to resatisfy
specified
no satisfactory
changes, constraints
solution
a constraint
(an assignment
an error is flagged. Key differences among
satisfaction
by changing
constraint
of other
to variables)
programming
constraint-satisfaction algorithms they support. ple incremental attribute evaluation algorithm one direction only. instance. ThingLab
algorithm
the values
of values
systems
of methods
references
If changing a updates b, changing II uses a more complex algorithm
to the
to the variables system,
one for
that each
‘L The absence of a method for a given variable indicating that the variable cannot be influenced ACM TransactIons
on Software
it constrains such
is invoked variables.
If
can be found, follow
from
the
b cannot update a, for that allows the system as an object
and that
variable.zl
Each
exports method
constitutes an implicit read-only by the presence of the constraint.
Engineering
[4], values When
OPUS uses a relatively simthat propagates changes in
to choose the direction in which changes propagate. In more detail, a ThingLab II constraint is implemented maintains
storing values.
and Methodology,
that a set must
annotation,
Vol. 1, No. 3, July
1992.
264
K. J. Sullivan and D. Notkln
.
guarantee
that
it resatisfies
the constraint
by setting
the value
as a function of the values of the other variables. Thus the system has a choice of which variable constraint.
Given
system computes affected (directly This
of this
suggests
object
an
opposed
and
set, which
is called
to
implicitly
invokes
to the
variable.
to conjunctive,
to change
a variable
to resatisfy
a
to be changed,
the
set of choices, one from each constraint object by the change. ThingLab II is incremental in
extension
a variable
attached
of constraints
a compatible or indirectly)
its computation changing
a set
of its variable
our
This
implicit
a plan.
implicit
invocation
one of the
model.
methods
can be characterized
invocation:
a select
Logically,
defined
in
each
as disjunctive,
procedure
as
chooses
one
method from this decision
those registered for invocation. on exactly the information used
systems this In contrast
choice might be based on performance or other considerations. to our approach, constraint systems guarantee global properties
based on an Both ThingLab ThingLab variable
II
analysis II and
ensures
are included
of their underlying constraint OPUS detect and prohibit cyclic that
no two
in the same
constraint
can
be
the
used
that change update both Both
limit
relationships to
constraints
Second,
constraint
capsulation,
and
other
than
their
respective
variables
can
relationships.
to variables,
hence
with
be specified,
and
ThingLab
can
as opposed
based data
to the
II
and This
same
only
mechanthat can
policies
prohibits
precluding mutual
methods
abstract
type
by
constraining
object-oriented language that This is a serious shortcoming
to help manage complexity in the face of integration. encapsulation are key tools for managing complexity;
en-
objects
variables
ThingLab
tightly with
types. with
abstraction:
of OPUS,
that
policies that dependencies.
are incompatible
behavioral is true
the
to arbitrary
on variables
be constrained
implementations.
writing
suitable as integration limit the components
one variable, for example, a relation. OPUS prohibits
systems
Kaleidoscope [9], an ThingLab mechanism. objective, tion and
that
maintain
more than a set and
methods
representations. dependencies, and
plan.
On the other hand, these systems are not isms for complex environments. First, they be related,
In these systems select bases in computing a plan. In other
II,
integrates respect to
in and the our
Type abstracand integra-
tion mechanisms compatible with these techniques are needed. Our approach supports the integration of arbitrary types, specification of arbitrary relationships, and definition of relationship-maintenance policies that respect type abstractions and encapsulation boundaries. 8. CONCLUSION 8.1
Limitations
Our approach has proven useful in a number systems that we have developed. Several problems have to be solved, however, for it to be applied in the development of larger integrated environments. First, a key problem is to extend it for design of concurrent and distributed environments. Some systems use atomic transactions to maintain global ACM
TransactIons
on Software
Engineenng
and Methodology,
Vol
1, No
3, July
1992
Reconcdlng Environment consistency
in the
combined that
with
this
transactions
with
a general will prove
research
in this
implicit
invocation
that
purpose;
suggests
with
that
our
.
can be
clear,
though,
the best way to balance
the need for global
practical
265
approach
it is not
We have yet to find
approach
FIELD
and Software Evolution
It appears
for this
solution.
of our lightweight
The experience without proach
face of concurrency.
nested
is a reasonable
the benefits
Integration
consistency.
environments
can be built
solution to this problem. Whether a mediator-based apuseful in such an environment is not known. To enable
dimension
we have
mechanism
designed
and are implementing
to complement
a remote
a remote
procedure
call
[2]
mechanism. Second,
reasoning
mechanisms
may
about
systems
not be easy
constructed
as the
scale
using
of systems
implicit
ence with medium-scale systems, such as the CAGD system gives us some confidence-but no conclusive evidence—that a serious present
problem.
Unconstrained
a reasoning
problem
implicit
(just
invocation
as unconstrained
approach accurate 8.2
to maintain
relationships
as a reasoned than
balance
considering
it as implicit
approach.
One
is to employ
programming
experi-
would,
in all likelihood,
explicit
invocation
would).
may account use explicit
components,
so considering
and
invocation
explicit
invocation
our
is more
alone.
Synthesis
Our
design
environments in order
to automatically
way
ensure
and global consistency, ThingLab II and OPUS
lar
among of implicit
Our
discussed earlier, scale will not be
However, designing with mediators is quite constrained, which for the absence of problems so far. Additionally, mediators invocation
invocation
increases.
to manage
that
basic
The a given
properties,
constructs
they
design,
such
support
tion. On the other hand, undisciplined impossible to reason about a resulting the familiarity the designer
tion techniques that changing requirements.
not
be appropriate
restrictions
they
Implicit first-class
invocation. abstraction, ACM
Our dual
Transactions
on Software
particurelation-
impose
for
imple-
may
exact
use of an imperative style can make it system. Our approach is intended to
software
approach to explicit
by
less restricted conand explicit invoca-
and flexibility of these imperative to control complexity by providing encourage
used
make them unsuitable as general and evolution of integrated envi-
may
and the semantic
semantics
as termination
mechanisms
significant tolls in decreased efficiency. Overcoming these problems may require semantically structs, such as imperative programming with implicit
exploit helping
of integrated
restricted
for problems suited to their they impose on components,
ships, and relationship-maintenance policies mechanisms intended to ease development ronments.
complexity with
hold. The change propagation represent such mechanisms.
These mechanisms are appropriate strengths, but the restrictions
m enting
the
constructs
structures
robust
constructs, while design composiwith
respect
to
includes implicit invocation as a invocation. We presented a model
Engmeermg
and Methodology.
Vol. 1, No. 3, July
1992.
266
.
K. J. Sullivan and D. Notkln
of implicit mechanisms. the is
invocation in terms of which Each of these placed a layer
event-method specified
cit
invocation
model
and
explicit
association,
indirectly to in
in
EM.
terms
a minimum
our
by
mechanisms,
and implicit
The
of
we characterized a number between the programmer and Smalltalk-80
object stripping
reveals
EM,
dependencies, away
more
this
clearly
for
instance,
Reducing layer,
the
impli-
as
duality
in
our
between
invocation.
We also showed how object-oriented languages can be extended easily to support our implicit invocation abstraction. Although we have only limited experience mechanisms
with this provides
model, its additional
utility in characterizing a diverse range of evidence that it, and hence our mechanism,
is reasonable. Design
tradeoffs.
Our
approach
encourages
the
decomposition
of require-
ments as well as designs nents from the integration
and implementations along lines separating relationships among them. Specifications
in this
designers
ment
regard
may
integration
in this
manner
We identified tradeoffs Given choose? designed
bias
and evolution. leave four
among
the
toward On the
designer
idealized
free
approaches
ease of integration,
a specification
in
In the absence for change. Our
this
to choose that
form,
that
hand,
among
and,
which
complicate
environ-
specifications
encourage
evolution,
of other analysis
we discuss, our mediator integrated environments.
designs
other
organized
a range designs
perhaps,
approach
of designs. with
distinct
efficiency.
should
concerns, a software system suggests that, of the canonical
approach yields the greatest An interesting characteristic
compothat fail
a designer should be approaches
ease of evolution of this approach
in is
that it preserves the specification relationships in both design and
structure separating components and implementation. In the absence of this
correspondence,
by the
which
is disrupted
other
unlikely that the overall cost of an evolutionary its apparent size in the specification. Although size
or proportional
client about
with
precision,
this
approaches
we discuss,
it is
change will be proportional to we cannot yet define apparent
property
is clearly
desirable:
the
specifies changes in terms of the specification and bases expectations costs on it. Designs that amplify actual costs for reasons not apparent
to the client
are likely
to prove
unacceptable
as requirements
evolve.
ACKNOWLEDGMENTS Tony
DeRose,
environments implemented Cabe’s helped Derrick
Bill
Griswold,
discussed the tools
experience significantly Weathersby
and Larry
Snyder
provided
the domains
with his CAGD system provided valuable feedback that in the development of our approach. Yoshi Yamane and contributed to the ideas of ABT composition and disjunc-
tive implicit invocation, respectively. Robert Wahbe pointed macros in simplifying the use of a C++ implicit invocation addition to many of these people, Gail Alverson and Michael ACM
Transactions
for the
herein. Alex Klaiber, Bob Mitchell, and Sitaram Raju in our parallel programming environment. Tom Mc-
on Software
Engmeermg
and Methodology,
Vol.
1, No. 3, July
out the utility of mechanism. In Hanson gave us 1992
Reconciling useful
comments
Environment
on an earlier
and suggestions
made
Integration
version
and Software Evolution
of this
by the anonymous
paper.
referees
Finally,
were
the
cogent,
267
.
comments
valuable,
and
appreciated.
REFERENCES 1.
BERSHAD, parallel
B.
N.,
LAZOWSKA,
programming.
2. BIRRELL, Comput.
A.
D.,
Syst. Not.
4. BORNINC+, A.
6. 7. 8. 9.
B.
LEVY,
H.
Exper.
18, 8 ( 1988),
J.
M.
PRESTO:
Implementing
A
system
for
object-oriented
713-732.
remote
procedure
call.
ACM
Trans.
1,(Feb. 1984), 39-59. Common
23 (Sept.
Lisp object system specification
X3J13. Dec. 88-002R.
ACM
1988).
The programming
language
aspects
of ThingLab,
a constraint-oriented
simula-
1981), 353-387. for a new generation of CAGAN, M. R. The HP SoftBench environment: An architecture software tools. Hez.ulett-Packard J. 41, 3 (June 1990), 36–47. Analyws. Yourdon Press, Englewood Cliffs, N J., COAD, P. AND YOURDON, E. Object-Or~ented 1991. of the 1989 COHEN, D. Compiling complex transition database triggers. In Proceedings ACM SIGMOD (Portland, Ore., 1989) pp. 225-234. FREEMAN-BENSON) B., MALONEY, J., BORNING, A. An incremental constraint solver. Comrnun. ACM 33, 1 (Jan. 1990), 54-63. FREEMAN-BENSON, B. N. Kaleidoscope: Mixing objects, constraints, and imperative proof OOPSLA / ECOOP 90, (Ottawa, 1990), 77-88. gramming. In Proceedings tion
5.
D.,
B-act.
AND NELSON,
2,
3. BO~ROW, D. G. ET AL. SZGPLAN
E.
So@J.
laboratory.
10. FROMME,
ACM
B. D.
Trams.
HP
Program.
encapsulator:
Lang.
Sys. 3, 4 (Oct.
Bridging
the
generation
gap.
Hewlett-Packard
J. 41,
3
(June 1990), 59-68. 11, GARLAN, D. Views for tools in integrated environments. Ph.D. dissertation, Carnegie-Mellon Univ., 1987, 12. GARLAN, D., AND ILIAS, E. Low-cost, adaptable tool integration policles for integrated enviof SIGSOFT90: Fourth Symposl am on Software Development ronments. In Proceedings Environments (Irvine, Calf., 1990), 1-10. 13. G~RLAN, D., AND NOTKIN, D. Formalizing design spaces: Implicit invocation mechanisms. In VDM
’91, Formal
Software
Development
Methods.
Lecture
Notes
in Computer
Sczence
551,
Springer Verlag, New York, 1991. 14. GRISWOLD,W. G., AND NOTKIN, D. Program restructuring as an aid to software maintenance. Tech. Rep. 90-08-04, Dept. of Computer Science and Engineering, Univ. of Washington, Aug. 1991. 15. GUIBAS, L.. AND STOLFI, J. Primitives for the manipulation of three-dimensional subdivisions. ACM Trans. Graph. 4, 2 (April 1985), 74–123. IEEE 16. HABERMANN, A. N., ANI) NOTKIN, D. Gandalf software development environments. Trans. Sofh.o. Eng. SE-12, 12 (Dec. 1986), 1117-1127. 17. HABERMANN, views.
Tech.
A. N., KRUEGER, Rep.
18. HELM, R., HOLLAND, tions
displays. 20. KELLER, and
Univer.
systems.
In
AND MOHAMED, Trans.
Znfi Syst.
Proceedings
S. P.
Contracts: of 00PSLA
Interactive
8, 3 (1990),
Jan.
environments: on Software
KRASNER,
G. E.,
interface
paradigm
Chiron-1
Engineering
AND POPE. in
The
S. T.
Smalltalk-80.
J.
Specifying
specification
system.
In
TransactIons
on Software
with
behavioral 90. 1990,
of flexible
composi169-180.
user
interface
User
Proceedings
interface
of the 13th
development International
Tex., May 1991), 208-218.
cookbook Object
for
using
Oriented
26-49. 22, LINTON, M. A., VLISSIDES, J. M., AND CALDER, P. R. 222 (Feb. 1989), 8-22. Views. Computer ACM
Programming
269-288.
(Austin, A
J.
1988,
/ ECOOP
R. K., CAMERON, M., TAYLOR, R. N., mm TROUP, D. B.
software
Conference
21.
S. E., ACM
177, Carnegie-Mellon
I. M., AND GANGOPAI)HYAY, D.
in object-oriented
19. HUDSON,
C., PIERCE, B., STAUDT, B., AND WENN,
CMU-CS-87-
Engineenng
the
model-view-controller
Composing
user
1, 3 (Aug. /Spet.
Program.
user interfaces
and Methodology,
with
Vol. 1, No. 3, July
1988 ), Inter-
1992.
268
.
K. J, Sullwan and D Notkm
23. MACDONALD,
J.
Proceedings 24. MCCABE, thesis,
T.
1991),
with
of Washington,
S.
J.
Difficulties
Nested
Dzstrzbuted
tools
Developing
multiview
1987),
views
of
a graphical
complex
mesh
objects.
In
environment.
M.S.
development
systems.
IEEE
(Jan.
Softw.
Second
L.
The
Workshop
31. SPIVEY, J. M. Chffs,
In Concurrency
introduction. Ed., Van
using
Nostrand
message
Control
Reinhold,
passing
New
in the field
and
York,
Relzabzlzty
zn
1987.
envmonment.
IEEE
Softw.
The Unix
time-sharing
system.
Bell
Syst.
Tech
J. 57, 6,
1905-1930.
Relations
30, SNYDER,
An
D. M., AND THOMPSON, K.
2 (July-Aug.
1987> 466–481.
as semantic
XYZ
constructs
abstraction
on Parallel
levels
Compilers
The Z NotatLon;
m an object-oriented
of poker-like
languages.
and Algor~t}Lms
A Reference
Manual,
language.
(Urbana,
In
Proceedings
Proceedings
of
the
111., 1989).
Prentice-Hall
International,
Englewood
N. J., 1989.
32. STEFIK,
M. J., BOBROW, D. G,
a multiparadigm
STROUSTRUP, B.
The C++
process-centered
Software
AND KAHN, K. M.
environment,
34. SUTTON, S., HEIMBIGNER, Development
TransactIons
IEEE
Programming
environments.
In
Enoz,ronrnents.
on Software
Softu,.
Integrating (Jan.
Language.
D., AND OSTERWEIL,
Received May 1991: revised December
ACM
multiple
57-66.
of OOPSLA,
in
mediators.
B. Bhargava,
29. RUMBAUGH, J.
33.
Painting 245-257.
in integrating
Connecting
1990),
(July
28. RITCHIE,
into
W. 1990,
1991.
transactions:
Systems.
27, REISS, S. P.
part
/ ECOOP.
49-57.
26. Moss,
7, 4
AND STUETZLE,
Programming
Univ.
25. MEYERS,
A.,
of OOPSLA
L.
Addison-Wesley, Language
Proceedz ngs (Irvine,
Calif.,
1990),
and Methodology,
programming
Vol
Reading,
constructs
of SIGSOFT90
1991: accepted February
Engineering
access-oriented
1986 ), 10– 18. Mass..
for managing Fourth
Sympos~um
206-217,
1992
1, No
3, July
1976. change
1992
on
