See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/2440188

PIROL: A Case Study for Multidimensional Separation of Concerns in Software

Engineering Environments

Article · August 2000

DOI: 10.1145/353171.353185 · Source: CiteSeer

CITATIONS READS
32 48

All content following this page was uploaded by Stephan Herrmann on 17 March 2013.

The user has requested enhancement of the downloaded file.

 PIROL: A Case Study for Multidimensional Separation of
Concerns in Software Engineering Environments

Stephan Herrmann Mira Mezini

Technical University Berlin Darmstadt University of Technology
D-10587 Berlin, Germany D-64283 Darmstadt, Germany
stephan@cs.tu-berlin.de mezini@informatik.tu-darmstadt.de

ABSTRACT fo using on only one dimension auses the denitions of on-

In this paper, we present our experien e with applying mul- erns in other dimensions to be tangled with the denition
tidimensional separation of on erns to a software engineer- of the on erns in the main dimension with negative ee ts
ing environment. By omparing two dierent designs of our on reusability, lo ality of hanges, understandability, hen e
system, we show the importan e of separating integration maintenan e, and ( ) the prin iple of separation of on erns
issues from the implementation of the individual on erns. be omes really ee tive when it is simultaneously supported
We present a model in whi h integration issues are en apsu- along multiple dimensions, with on erns in dierent dimen-
lated into rst{ lass onne tor obje ts and indi ate how this sions overlapping ea h other.
fa ilitates the understandability, maintenan e and evolution
of the system. We identify issues of binding time, binding While the idea of multidimensional separation of on erns
granularity and binding ardinality as important riteria in (MDSOC) is more than intuitive, and programming models
sele ting an appropriate model for separation of on erns. for supporting it are emerging [22, 28, 49℄, an investigation
We nally show how a good hoi e following these riteria of the design spa e of su h models is still missing, partly
and onsidering the requirements of software engineering en- due to the la k of experien e reports on applying MDSOC
vironments leads to a system with dynami ongurability, to the onstru tion of moderately sized software. In this
high{level omponent integration and support for multiple paper, we make a modest eort to ll this gap by reporting
instantiable views. our experien e with applying the prin iple of MDSOC to
a real software engineering environment (SEE). SEEs are
Keywords integrated environments onsisting of a olle tion of software
Separation of on erns, software engineering environment, engineering tools that work together, freeing the user from
domain{spe i language, omponent integration. the need of manual oordination [48℄. Hen e, although our
ase study is an SEE, the results of the work presented here
apply to any integrated environment, for whi h SEEs are
INTRODUCTION just one example.
The prin iple of separation of on erns [7, 36℄ has made its
way into all modern software formalisms, bringing about As any other integrated environment, SEEs are omplex sys-
many dierent on epts for breaking a system into parts, tems that support very dierent a tivities. Dierent team
with the obje t on ept being the most re ent one. In members a t in dierent roles su h as developer, administra-
the last de ade, a \post{obje tive" era has emerged rep- tor, proje t manager, et . On the other side, development
resented by role and ollaboration based designs [39, 18, 46, goes through dierent stages. Both dimensions refer to and
51℄, re e tive ar hite tures [25, 21, 26, 27℄, and more re- manipulate the same produ t: a model of some problem do-
ent approa hes su h as aspe t oriented programming [22℄, main | to be rened up to exe utable software | whi h
programming with reusable ollaborations [28℄, and the mul- is itself split into dierent stage{spe i artifa ts. Due to
tidimensional separation of on erns model [49℄. The main this variety of on erns and fa ets involved, the design of an
message of this \post{obje tive" era [15℄ is that (a) exist- SEE provides a good ase study for applying multidimen-
ing software formalisms support separation of on erns only sional separation of on erns. Our ase study is a medium
along a \predominant dimension" (e.g., the data type axis in sized SEE, alled PIROL, developed at the Te hni al Uni-
obje t{oriented languages as opposed to fun tions in pro e- versity of Berlin, Germany.
dural programming) while negle ting other dimensions, (b)
The ontribution of the paper is twofold. First, it presents a
ACM, 2000.
– Pre-print – To appear in proceedings of OOPSLA 2000
Permission to make digital or hard copies of part model for MDSOC in integrated environments with a strong
or all of this work for personal or classroom use is granted without fee support for evolution. Not only does the model allow dier-
provided that copies are not made or distributed for profit or commercial ent tools to be developed independently of ea h other; more
advantage and that copies bear this notice and the full citation on the importantly, it preserves this independen e beyond integra-
first page. Copyrights for components of this work owned by others tion time. Obviously, software evolution is easiest when sys-
than ACM must be honored. Abstracting with credit is permitted. To tem omponents are independent. However, independen e
copy otherwise, to republish, to post on servers or to redistribute to lists, is a hallenging goal in integrated environments, where in-
requires prior specific permission and/or fee. tegration requires ne{grained oordination of the involved

1
 omponents. The design presented in this paper solves this Q5: Binding ardinality: Can on erns be applied mul-
trade{o by separating the denition of tool integration re- tiply? Can elements of a on ern be mapped to mul-
lationships from the tools themselves. tiple elements of another on ern?
Again PCAs are an example for exibility, whereas,
Our design is based on the repository ar hite tural style [45℄, e.g., in SOP ea h element from one on ern an only
where all tools are to be integrated with the shared repos- be bound to (at most) one element from ea h other
itory. We distinguish between two levels of integration. At on ern.
what we all the \physi al" level, a basi \wiring" between
de oupled tools is enabled by means of a uniform ommu- As we see, emerging MDSOC models answer these questions
ni ation proto ol. This wiring merely allows omponents to dierently. Also our experien e shows that when applying
ex hange messages, implying, however, that the parti ipants MDSOC to omplex systems su h as SEEs, there is indeed
ex hange data of the same type. However, if tools are devel- no single answer to most of the questions above. Due to the
oped independently from their ontext of use, mismat hes many trade{os that need to be solved in su h a system,
in their domain models are very likely. We all \logi al" several o-existing alternatives should rather be supported.
the level of integration responsible for handling these mis- Our answer to Q1 will be that standard obje t{oriented on-
mat hes. We ompare a design in whi h logi al integration epts enhan ed by some semanti ally useful on ept of mod-
is mainly a matter of tools, i.e., ea h tool is responsible for ules a tually suÆ e for the separate denition of tools and
the onversion of the data it ex hanges with the repository, repository. However, domain{spe i language features and
with a design in whi h logi al integration is separated out onstru ts appear to be better suited for expressing lower{
of the tool denition. We show the superiority of the lat- level on erns related to system properties, su h as syn hro-
ter approa h with respe t to maintainability, reusability and nization, persisten y, et ., sin e these intera t with the other
evolution. on erns at a very ne{grained level. Similar trade{os have
to be solved with respe t to Q2. While the expli it integra-
The se ond ontribution of the paper onsists of an evalu- tion layer, supported by advan ed language onstru ts, is
ation of PIROL's design along a set of questions that an the key to enabling true independen e of tools, other on-
be used as a basis for omparing the hosen approa h with erns, for whi h this independen e is not an issue, should be
other MDSOC models. The questions we onsider are: integrated more dire tly be ause the additional layer would
unne essarily in rease the system omplexity in terms of the
Q1: Spe ialized language support: Is spe ialized (do- number of units to be developed and might ae t perfor-
main{spe i ) language support beyond the standard man e, as well. It is obvious that run{time binding (Q3 )
obje t{oriented model needed for enabling separate yields a greater exibility, whi h has to be balan ed, how-
denition of on erns? ever, against the ost in ode omplexity and exe ution time.
For instan e, the aspe t language D [24℄ provides Possible answers to Q4 also range from single attributes up
highly spe ialized onstru ts for the syn hronization to omplex modules. We will demonstrate the benet of
and distribution on erns. In most other approa hes allowing all levels of entities in a on ern mapping, espe-
the a tual implementation of on erns relies mostly ially in luding a kind of module level that en apsulates a
on standard obje t{oriented notions. set of ollaborating obje ts. In a similar vein, we will show
examples where exibility in binding ardinalities (Q5 ) is
ru ial.
Q2: Expli it integration: Is on ern integration dened
separately or is it part of the on ern denitions? To summarize, our experien e with PIROL suggests that
The models of subje t oriented programming (SOP some form of \uni ation" of the MDSOC models is needed
[15℄) and Pluggable Composite Adapters (PCA [29℄), that supports alternative answers to the above questions
allow to dene integration in separate units whereas, (and others not onsidered here) regarding on ern de om-
e.g., in Aspe tJ [35℄ on erns and their integration position and omposition. This requires a systemati inves-
are dened in the same pla e. tigation of the design spa e of MDSOC models, whi h would
result in the denition of a \meta{model" for MDSOC soft-
ware formalisms in order to fa ilitate the ombination of
Q3: Binding time: Are on erns bound at ompile, link several MDSOC te hniques. This paper does not ondu t
or load time or an binding be delayed until run{time? su h an investigation. With the evaluation of PIROL's de-
The role obje ts in delegation based approa hes (e.g., sign along the questions posed above, we only give rst hints
[42℄) still exist at run{time and an by bound dy- about the dire tion of this investigation and provide some
nami ally. On the ontrary, in SOP dierent on ern eviden e for its usefulness.
denitions are merged together at ompile{time.
The remainder of the paper is organized as follows: In Se t. 1,
Q4: Binding granularity: Whi h entities in on ern we present the initial design of PIROL based on a MDSOC
denitions an be mapped to ea h other ? model without expli it support for integration of tools with
PCA's onstru ts of ollaborations and omposite mismat hing data models, and indi ate the short oming of
adapters are examples for higher{level units of on- this approa h with respe t to reusability, maintenan e and
erns and their integration. All relevant approa hes tra eability. In Se t. 2, we introdu e an expli it integra-
allow mapping at the level of lasses and their tion dimension and use lass graphs as the top{level binding
features. unit. Se t. 3 evaluates this design along the questions posed
above. Se t. 4 presents related work, while Se t. 5 on ludes
the paper and outlines areas of future work.

2
 Tool B Tool A <<proxy>>
Tool Tool Tool Tool A: TOOL
invoke(5)
getFont()
<<proxy>> getDefaultHost()
Session Workbench Workbench Session M: Menu getProgramPath()
User A User B select(obj: ANY)
invoke(5) changeFont()

Message channel message types:

(a) Local method invocation A: TOOL
Repository
Data access font
(b) Request: defaultHost
Tool asks Workbench programPath
M: Menu
Figure 1: Overall ar hite ture of PIROL (c) Changed message:
Workbench notifies Tool
invoke(opt:int)
start()
shutdown()
select(o5) isActive()
(d) Tool Request: select(obj:ANY)
Workbench delegates to Tool Workbench
1. FIRST DESIGN OF THE SEE PIROL
From the very beginning, separation of on erns has been Figure 2: Messages between tools and workben h
an important rationale in the design of PIROL [14, 38℄. This
is due to the goal to build a generi SEE framework that al-
lows independent tools to be losely integrated. Independent lifted to dynami Lua/P obje ts, whose methods are exe uted
means that (a) there are no expli it inter{tool invo ations, within the workben h. Hen e, Lua/P lasses dene PIROL's
and (b) tools are developed for their own data model. Tools full meta model, referred to as the repository model through-
may be delivered as pre- ompiled units, whi h run as sepa- out this paper and representing the universe of abstra tions
rate pro esses, possibly a ross ma hine boundaries. shared by all tools. For lient pro esses the workben h very
mu h resembles an OODBMS, with some additional features
Yet, within the integrated environment tools (a) share a that are not dis ussed here. Finally, Tools provide the only
ommon universe of basi abstra tions | the intrinsi model means for user intera tion.
of a pie e of software under development as well as the de-
velopment pro ess itself { and (b) intera t with ea h other As shown in Fig. 1, the ommuni ation between tools and
in performing some fun tionality, while ( ) still preserving the workben h (as well as workben h{to{workben h mes-
their independen e. As pointed out in [48℄, preserving tool sages) happens via an expli it multi ast messaging fa ility,
independen e is ru ial for fa ilitating evolution in an in- that is based on the MSG pa kage of the FIELD environ-
tegrated environment, implying both (a) repla ement of a ment [40℄. In order to ommuni ate, tools and the work-
tool with a new version of it and (b) a-posteriori integration ben h onne t as lients to the messaging fa ility and reg-
of new tools. Our experien e suggests that tool indepen- ister as observers of ertain events. Due to this de oupled
den e beyond integration time is ru ial also for enabling ommuni ation, tools may be implemented independently
exible binding ardinalities, allowing e.g., shared data to and in any language (that an interfa e C | the language
be simultaneously displayed and manipulated by multiple in whi h MSG is written). They a ess obje ts in the repos-
tools and/or multiple o-existing do uments belonging to itory by means of proxy lasses, that (via MSG) transpar-
the same tool, whereby the involved tools or do uments ently delegate all a esses to the workben h by means of set
may have spe i , partially overlapping \per eptions" of the and get methods as well as method wrappers ( f. message
shared data. type (b) in Fig. 2)1 .
In this se tion, we show how a set of te hniques for sep- The repository ar hite tural style [45℄ also requires a me h-
aration of on erns, most of whi h are well explored, was anism for automati hange propagation. The workben h is-
ombined into our rst design of a framework for integrated sues hanged messages for ea h value that is hanged within
environments, that partially met our goals, but still suered the repository (( ) in Fig. 2). Tools register with the mes-
from some short omings. An analysis of these short omings saging servi e as observers of su h messages installing the
motivates the introdu tion of another level of separation of ne essary allba ks for updating the tool's display and in-
on erns into our design to be presented in Se t. 2. ternal data whenever a relevant hanged message is issued
to the message hannel. The me hanism of hange propaga-
tion is thus de omposed into three on erns: (1) the work-
1.1 Achieving “physical” independence ben h is responsible for generating hanged messages, (2)
A rst requirement was to provide a basi generi infrastru - the message fa ility dispat hes these messages to the regis-
ture that enables independent tools to \talk" to ea h other tered observers and (3) tools only need to implement their
even if they do not expli itly know about ea h other. For spe i rea tion (redisplay et .).
this purpose, PIROL was designed with a three{tier ar hite -
ture (Fig. 1). The repository provides a entral data storage In addition to this data driven ommuni ation, PIROL also
in luding basi servi es su h as s hema management, a ess allows one tool to (indire tly via the workben h) invoke
ontrol, and transa tions. The repository s hemas dene the methods of another tool. For this purpose, the workben h
stati part of PIROL's meta model. The workben h denes represents ea h tool by an obje t of the Lua/P lass TOOL.
a user's session. It ontains an interpreter for the obje t{
oriented repository language Lua/P [16℄, that fully en ap- 1
Most tools are urrently implemented in Java, for whi h a
sulates the repository in that data from the repository are library of proxy lasses exists.

3
 subsystem Package
SUBSYSTEM
from
classes classes links
CLASS RELATION GeneralClass Link
2 * name : String
name : String line : List(Point)
position : Point
is_deferred : Boolean

features type TYPE Class ImportedClass

FEATURE name : String abstract : Boolean
shrink : Boolean

ENTITY ROUTINE
attributes methods
Attribute Method
Figure 3: Extra t from the repository's meta model type: String

Figure 4: Meta model of a tool for UML lass dia-

This lass has methods that delegate exe ution (via the mes- grams.
saging fa ility) to the running tool pro ess ((d) in Fig. 2).
This feature is used e.g., to implement the notion of a on-
text menu that enables the user of a tool to start or oth- latter is mainly a graphi al abstra tion, dened in terms
erwise ontrol other tools. When a tool (say, Tool B in of its position and appearan e (the latter is determined by
Fig. 2) requests the ontext menu for a given obje t, the the attributes shrink, responsible for ollapsed display of
workben h ongures a menu denition in the shape of a a symbol, and abstra t, toggling itali /non-itali fonts).
repository obje t based on the knowledge about urrently Furthermore, a CLASS obje t has a single list of features
installed tools and their features. The tool displays the ( f. Fig. 3), whereas lasses as seen by a UML{diagram ed-
menu and lets the user sele t an option. Now, the method itor keep separate lists for Attributes and Methods, whi h
invoke(optionIndex) ( alled on the menu proxy and passed are drawn in dierent se tions of a lass symbol in a UML{
to the menu repository obje t) may, e.g., result in a all of diagram. Another dieren e on erns the representation of
the method sele t to the TOOL obje t that represents A in the type of an attribute. In Fig. 3, the type of a FEATURE
the workben h. The latter all is nally forwarded to the (and its sub lasses) is represented by the lass TYPE. On the
pro ess running tool A. ontrary, a simple string is perfe t for representing the type
of an Attribute within a UML lass symbol ( f. Fig. 4).
To summarize, the message hannel provides a generi Thus, some abstra tions in a tool's meta{model have dire t
\wiring" whi h enables a physi al de oupling between tools orresponden es to abstra tions in the repository model,
and the workben h. It is impli it with the message han- e.g., name, others an be somehow derived from abstra -
nel that tools are not only separate pro esses but they may tions in the repository model, e.g., attributes and methods,
be distributed all over the internet. Deploying a tool with and yet others are ompletely new, e.g., the position in
spe ial resour e requirements to a dedi ated host is simply GeneralClass.
ongured by means of the TOOL obje t.

1.2 Striving for “logical” independence Storing shared versus tool–specific data
Given the dieren es in the meta models and our goal to fa-
The infrastru ture presented so far enables \physi al" ilitate the evolution of the integrated environment with new
\wiring" of tools and repository. As also pointed out in tools, tool{spe i abstra tions, e.g., a lass diagram or any
[4℄, this basi wiring is, however, not enough. Allowing do ument, are not dened as part of the repository model.
ea h tool to be developed independently with its own data Instead, we distinguish two kinds of persistent obje ts: the
abstra tions requires also some form of logi al pluggability regular repository obje ts (RO) are dened by PIROL's basi
responsible for dealing with mismat hes between the data meta model and arry all information that is to be shared
models of tools and PIROL's meta model. between tools. In addition, do uments that are manipulated
by tools are modeled as a spe ial type of persistent obje ts,
Meta model mismatches alled on eptual obje ts (CO). A CO denes a spe i view
The repository model in ludes only elements that ontribute onto a set of ROs: it en apsulates additional properties of
to the stru ture and semanti s of the system under develop- ROs, relevant for the view at hand. For instan e, a CO for
ment. Classes in the repository model are, e.g., SUBSYSTEM, a UML diagram en apsulates graphi al information about
CLASS, FEATURE et . ( f. Fig. 3). Dierent tools have, in the (CLASS) ROs in luded in the diagram su h as their po-
general, their own spe i abstra tions. For instan e, the sitions, fonts, expand/ ollapse ags, et . Do ument spe i
meta{model of a on rete graphi al editor for (a variant of) properties are stored in a CO basi ally as a hash table; ea h
UML lass diagrams, alled ZooEd [31℄, whi h we will use entry in the table asso iates a value to a key{pair onsisting
as an example throughout this paper, is presented in Fig. 4. of the name of a tool{spe i property and the ID of the
This model denes the abstra tions on whi h the editor op- RO to be de orated with this property. COs are persistent
erates and whi h it needs to store in the repository. obje ts with an open stru ture: a tool may store arbitrary
properties for any RO without prior de laration.
Note, that the two models in Fig. 3 and Fig. 4 are om-
pletely independent of ea h other. For instan e, when om- For illustration onsider the s enario presented in Fig. 5. In
paring the lass abstra tions in both meta models, namely the upper part of the gure two do uments are shown as they
CLASS in Fig. 3, and Class in Fig. 4, it appears that the are displayed to the user of the graphi al editor, represent-

4
 created by a User Working with dierent views of shared data omes with the
Documents:
risk of ompromising the semanti al integrity of the shared
Accounting Customers
data, sin e hanges may be performed within a view, that
Account does not see the full shared data model nor its invariants.
balance : Amount
Customer
Lua/P's me hanism of guarded attributes (see [16℄ for details),
name : String
address : Address
whi h allows a ess{oriented programming omparable to
Customer LOOPS' a tive values [47℄, omes into play here. Attribute
from Customers guards introdu e an additional layer between regular ma-
nipulation of ROs and their persistent representation, in-
Proxies for
implemented by a Tool ter epting all a ess to an RO attribute and implementing
Persistent appropriate poli ies of enfor ing onstraints over repository
Objects: #co2 : CO
data. For instan e, by atta hing a guard to the is deferred
#co1 : CO
name = "Customers"
ag of a ROUTINE, the following onstraint an be enfor ed:
\ea h lass that has at least one deferred routine is deferred,
name = "Accounting"
ROID property value ROID property value
COs: #c1 position (10,42) #c1
position (7,20) too". So when hanging a ROUTINE to deferred, it is ensured,
that also the CLASS will be set to deferred, if it was not al-
#c2 position (2,4) shrink False
...
...

#c1 :CLASS
ready deferred before. The hange is propagated from one
RO to another. As attribute guards sit below every view
ROs: name = "Customer"
...
#at1:AT denition, integrity onstraints as implemented by means of
guards apply to repository a ess independent of the view
from whi h it originates. That is, PIROL's repository model
stored in the Repository
omes with a meta{level ex lusively responsible for en od-
ing and maintaining onstraints that ensure the semanti
Figure 5: Do uments are implemented as COs integrity of repository data, no matter what views will be
dened over that data and how they a ess it. As an aside,
note that hanges on the repository aused by the exe ution
of a poli y asso iated with a guarded attribute are propa-
gated to interested tools (views) in the same way as hanges
ing two dierent pa kages, A ounting and Customers. The dire tly originating from some tool a ess.
symbol for the lass Customer appears in both diagrams (it
is dened in one pa kage and used in the other). The lower Logical tool integration
part of the gure shows a subset of the persistent obje ts Having intrinsi and tool{spe i features of a tool obje t
that represent the two do uments in the repository. Ea h en apsulated within dierent obje ts in the repository also
Class obje t manipulated by the tool is represented by two poses the question of how and where to (logi ally) integrate
dierent obje ts in the repository. Intrinsi information is these two distin t feature sets to onstru t a single obje t
stored within a CLASS obje t, while tool{spe i properties as seen by the tool. Stated dierently, the question is how
are stored within on eptual obje ts, one for ea h do ument. to map the features of a tool obje t to respe tive features
E.g., the appearan es of Customer in the A ounting, re- in the orresponding RO{CO pair in the repository. The
spe tively Customers lass diagrams, orrespond to two RO{ approa h taken in the rst design of PIROL was to in-line
f
CO pairs in the repository, # o1, # 1 and # o2, # 1 g f g this mapping fun tionality into ea h tool's implementation.
respe tively. The rst line in # o1 reads: CLASS obje t # 1 If this mapping was not taken into a ount during a tool's
is drawn at position (10,42) within the rst do ument. development, its sour e ode had to be modied at integra-
tion time. For illustrating some advantages and pitfalls of
This separation of intrinsi from tool{spe i on erns into PIROL's design, as presented so far, we brie y report the
two distin t repository obje ts, i.e., beyond ompile{time, experien e with integrating ZooEd [31℄, whose sour e ode
is ru ial. It allows e.g., the same CLASS obje t to appear was available to us.
at dierent positions and with dierent representations in
dierent do uments. The idea is that (a) there might be We integrated ZooEd into our SEE framework by follow-
several tool{spe i (overlapping) denitions orresponding ing three steps: (1) dening a stru tural mapping between
to the same base abstra tion, and (b) the de ision whi h one ZooEd 's obje ts and their representations in the repository,
to use might depend on run{time state and/or ontext. This (2) ensuring that user intera tions trigger the appropriate
is what we referred to as exible on ern binding ardinality repository updates using the dened stru tural mapping and
in the previous se tion. If integration of dierent on erns (3) making sure that the dened stru tural mapping was also
was based on ompile{time weaving of all partial denitions used to translate messages from the workben h to appropri-
into one whole, as e.g., with IBM's MDSOC model [34℄ or ate updates within the tool.
Garlan's model of basi views [9℄, it would be diÆ ult to
express the fa t that the same lass obje t should appear The rst step was realized by dening adapter lasses for
dierently depending on whether the pa kage being shown all lasses in ZooEd 's meta{model ( f. Fig. 4). The obje t
in an UML lass diagram owns or imports the lass at hand. stru ture in Fig. 6 shows how an adapter obje t mediates
Furthermore, it would be impossible to have the same lass between a tool obje t and proxies to repository obje ts that
simultaneously displayed in as many dierent positions, as store the data for the tool obje t2 .
there are UML do uments on the display that ontain the
2
lass. The gure shows the simplest ase of mapping exa tly one

5
 aCl: Class aClAdapter: ClassAdapter aClRo: CLASS the repository model is what we gained from the separa-
name: Customer tObj nameUpdated(...) rObj
<<proxy>>
tion of on erns within the meta model en oded by the RO{
CO distin tion along with tool en apsulation using the lass
position: (10,20) positionUpdated(...) roId: roId_1
attributesUpdated(...)
TOOL.
attributes: ...
...
methods: ...
... cObj
doc1: CO
<<proxy>> 1.3 Drawbacks of the first design
setProperty(...) The ZooEd example reveals several drawba ks of en oding
getProperty(...)
... logi al integration on erns into the tool's implementation3 .
TOOL (Java objects)
Workbench (Lua/P objects)
First, the stru tural mapping between both models is hand{
oded multiply. For instan e, all three following adaptations
aCO: CO implement essentially the same stru tural mapping (if we
ignore the dire tion of mapping):
aCLRO: CLASS
roId: roId_1

 Ea h ommand obje t needs to retrieve one or more

roID property value name:Customer
position (10,20) features: ...
roId_1 shrink ....

...
false
appropriate adapter obje ts and all the appropriate
... ... ...
update method(s) in order to write relevant hanges
to the repository.
 Ea h adapter obje t needs to rea t to hanged mes-
Figure 6: Stru ture of adapter obje ts. sages from the workben h. For this task, it needs to
know (a) whi h tool{internal obje ts should be mod-
ied and (b) how to trigger the appropriate redisplay
For the se ond step, it was ne essary to nd all pla es in within the editor. Espe ially diÆ ult is the tra king
ZooEd 's ode where relevant hanges to the tool's internal of hanges of CO properties: be ause all properties are
data happened, so that a tions on the appropriate adapters stored in just one table it is not trivial to nd the ap-
ould be triggered. Fortunately, the design of ZooEd on- propriate adapter obje t that is able to propagate the
sequently used the ommand pattern [8℄ to model all \rel- hange to the right obje ts.
evant" user intera tions with the tool. For all ommand
lasses, the relevant adapters had to be identied (this re-  To display a lass diagram from the repository, ea h
quired some administrative fun tions for adapter retrieval), adapter implements a traversal over all omponents of
and hanges had to be lassied su h that ea h ommand its adapted RO. During this traversal, new tool ob-
ould trigger appropriate updates of the repository via the je ts, to be in luded within the drawing area, as well
adapter ( f. the methods nameUpdated et . in Fig. 6). Note, as proxies to the orresponding ROs and orresponding
that the ommand lasses had to be modied in pla e: sub- adapters are reated.
lassing was not feasible in this ase, be ause reation of
ommand obje ts (i.e., referen es to ommand lasses) is Hen e, stru tural mapping is spread over the tool implemen-
spread all over the tool. tation, tangled with ode that implements other on erns
su h as hange propagation (adapters) and basi tool fun -
For realizing the third step above, in addition to translating tionality ( ommands, iteration of obje t stru tures et .).
hanges from the tool to repository hanges, ea h adapter Changing the implementation of one aspe t will probably
obje t is also responsible for listening to hanges in the unne essarily ae t the others: they an not be reused in-
repository and reverse{translating them to hanges in the dependently of ea h other. For instan e, after the in-pla e
state of tool obje ts. This ould involve dire tly manip- modi ation it is impossible to reuse the implementation of
ulating one or more tool obje ts (possibly repeating ode the tool's basi fun tionality with another repository model
very similar to that of some ommand lass) or reating (or with a modied model of the same repository). On the
and onguring a ommand obje t that ould perform the other hand, dierent versions of a tool annot reuse (parts
hanges. In the latter ase, great are had to be taken in of) the stru tural mapping aspe t. One an envisage an
order to avoid innite hange loops that would o ur, if om- upgrade of the UML diagram editor ZooEd.v2 that sup-
mands triggered by user intera tion were indistinguishable ports presenting the symbols for inner lasses a la Java [2℄
from those invoked in response to a noti ation from the as graphi ally ontained within the symbol of the en losing
workben h. lass. Evidently, the integration of ZooEd.v2 ould reuse
mu h of the stru tural mappings of ZooEd.v1P (the old ver-
Apart from these three steps, only the top{level lass had to sion with adaptation for PIROL), sin e the data model of
be modied, in order to onne t to the workben h and in- ZooEd.v2 would be a \renement" of ZooEd.v1 's model.
stall the initial adapters. No hanges to the repository were However, if the adaptation ode is hand{ oded into the im-
required ex ept for reating a new instan e of type TOOL, plementation of ZooEd.v1P, the stru tural mapping does not
that represents ZooEd and maintains its basi ongura- exist in one pla e and annot be reused. This is s hemati-
tion. Being able to integrate a new tool without hanging ally represented in Fig. 7.
3
tool obje t to one RO (plus the CO representing the do - Note, that the drawba ks dis ussed here apply to both the
ument). Generally, an adapter mediates between more ob- ase when stru tural mapping is in luded in the tool imple-
je ts on either side and manually implements the knowledge mentations from the very beginning, and the ase, when it
of how data interrelate in both dire tions is inserted later via in-pla e ode modi ations.

6
standalone Tool ZooEd.v1
T.v1
develop
ZooEd.v2
T.v1
2. DYNAMIC VIEW CONNECTORS
The short omings of the rst design have motivated the in-
adapt adapt again trodu tion of an expli it onstru t into Lua/P where to dene
no reuse the stru tural mapping ne essary for integrating a tool into
the environment. The new onstru t, alled dynami view
integrated in PIROL ZooEd.v1P
T.v1 ZooEd.v2P
T.v1 onne tors (DVC), is implemented as a spe ial Lua/P lass
whose instan es build a new abstra tion layer between tools
and the workben h. We all this additional abstra tion layer
Figure 7: Adapting onse utive versions of ZooEd virtual repository. Ea h tool has its own virtual repository
| a simulation of a repository that mat hes the model of
the tool. The virtual repository is implemented by DVCs on
A se ond design of the urrent design is that the properties top of the given design using COs. They will, however, hide
stored in COs are handled as improper attributes: expli it COs and provide for uniform a ess to RO attributes and
queries to the CO are needed instead of dire t attribute a - properties in COs. In the following, we rst present a rough
ess at the RO. Also, no type information for CO{properties sket h of what kind of obje ts live in a virtual repository
exists. As a result, no type he king is possible on these (Se t. 2.1) before going into the details of how to dene it
properties, and their orre t use depends solely on the pro- (Se t. 2.2).
grammer's dis ipline.
Last, but not least, the design presented so far assumes that 2.1 The structure of virtual repositories
the sour e ode of tools is available. This is not always the It is obviously preferable to have a repository whose model
ase, sin e tool providers want to prote t their intelle tual mat hes the model of a tool to be integrated: the tool sim-
property. This is where many proje ts of tool integration fail ply works with proxies to repository obje ts responsible for
and it may in fa t be the most important reason for striving bridging the language barrier between the tool and the work-
for a separation of tool implementation and its stru tural ben h and no adaptation is ever needed. However, in an
mapping to the repository. environment where the repository must meet the needs of
many tools, adjusting the repository to all tools would yield
a bloated repository model with many redundant denitions
1.4 Summary so far introdu ing immense onsisten y problems, let alone its non-
We distinguished between two fa ets of tool independen e ohesive stru ture and name lashes.
to be onsidered by tool integration: physi al versus logi- Our solution to this trade{o is to simulate a best mat hing
al. Two tools are onsidered as \physi ally" independent,
if they do not expli itly invoke or otherwise referen e ea h repository for ea h tool | this is what we all a virtual
other. PIROL supports the integration of \physi ally" inde- repository. Instead of having the stru tural mapping for a
pendent tools by means of: (a) its three{tier ar hite ture, ertain type in the tool's model being spread around the tool
where tool intera tion with the repository and other tools is implementation, dene virtual repository lasses (VC) that
expli itly modeled by the messaging fa ility and the work- en ode exa tly this mapping at a single pla e by providing
ben h, and (b) its impli it invo ation [48℄ me hanism based an abstra t view of underlying \real" repository abstra tions
on the messaging fa ility4 . As argued in [48℄, a design based (VC may also be used as an a ronym for \view lass"). A
on impli it invo ation via an intermediate unit satises the VC may also add new features as they are needed by the
requirement for \physi al" independen e5 . tool. There is a 1:1 relation between instan es of the tool
and virtual (or view) obje ts (VOs), the latter serving to the
Lua/P interpreter as \dispat hers" for attribute a esses on
Two tools are logi ally independent, if their data models are the former.
independent. The design of any integration framework has
to deal with this kind of independen e, as well. The question For illustrating the idea, Fig. 8 redraws Fig. 5 in the presen e
we pose here is how to do so without ompromising the ease of VOs. Until now it was the tool's responsibility to map
of evolution in an integrated environment. We laim that ea h obje t from its data model to an RO and a CO in the
expli it support is required for this kind of logi al intera - repository (this mapping was not represented in Fig. 5, as
tion between tools justifying this laim by the drawba ks of it is not lo alized in a single pla e within the tool). The
the design of PIROL as presented so far, where independen e additional layer in Fig. 8 performs exa tly this mapping.
is a hieved at the ost of a lear and maintainable stru ture. A tually only obje ts # 1, # o1 and # o2 are persistent.
While at the repository level, intrinsi and tool{spe i ab- Obje ts #i 2 and # 3 exist only during a user session and
stra tions are learly separated into dierent persistent ob- merely en ode a mapping fun tion. However, for the tool
je ts, mapping between tool and repository models is not they appear to be repository obje ts. That is why we all
expli it, but rather in-lined into the tool's implementation: them obje ts of a virtual repository. A VO is identied by
a design that impedes evolution. the ID{pair (roid x oid) referring to the RO{CO obje t
pair (as already seen in the old design) that is now virtually
4
Note, that also attribute guards are invoked impli itly, i.e., merged into a single abstra tion.
without the aller's knowledge.
5
There is no distin tion between \physi al" and \logi al" One an think of VOs as implementing roles [42, 52℄ of real
independen e in [48℄: what they deal with is a tually only ROs: e.g., ImportedClass is a role, that any CLASS obje t
the physi al aspe t of tool independen e as onsidered in may a quire in the ontext of a UML lass diagram. A -
this paper. quiring a role means eventually to gain new properties (e.g.,

7
 Documents: Accounting Customers omponent interfa e GRAPH f
interfa e Node f position : Point g
Account interfa e Edge f line : List(Point) g
Customer g
balance : Amount g
name : String omponent interfa e UML CLASS DIAGRAM inherit GRAPH f
address : Address interfa e Pa kage f
Customer name : String
from Customers lasses : List(Class)
links : List(Link)
method ndClass (name: String) : Class
manipulated by a Tool g
interfa e GeneralClass inherit Node f
name : String
#ic2:ImportedClass #c3 :Class g

VOs: name = "Customer"

interfa e Class inherit GeneralClass f
name = "Customer"
position = (7, 20) Virtual abstra t : Boolean
Virtual
position = (10, 42)
shrink = False Repos. shrink : Boolean
... (#co2) attributes : List(Attribute)
Repository(#co1) methods : List(Method)
mapped by a DVC reation pla e
method pla e (name: String, pos: Point)
g

#co1 : CO #co2 : CO ...other interfa es

g
name = "Accounting" name = "Customers" g
ROID property value ROID property value
COs: #c1 position (10,42) #c1
position (7,20)

Figure 9: Expe ted interfa e for UML lass dia-

#c2 position (2,4) shrink False
...
...

#c1 :CLASS
grams.
ROs: name = "Customer" #at1:AT
...
Real Repository editor is implemented without any knowledge of the reposi-
tory model.6
Figure 8: A virtual repository simulates tool obje ts Integrating a tool into the environment requires to \imple-
ment" its expe ted interfa e, by dening how elements of
the tool model are omposed from orresponding ROs and
position). Note that the same base obje t may play dier- by introdu ing additional features that might be missing
ent roles in dierent ontexts. For instan e, # 1:CLASS in from the repository model. This is realized via a onne -
Fig. 8 plays an ImportedClass role within the ontext of the tor lass. A onne tor instan e is a rst{ lass obje t that
A ounting diagram and a Class role within the ontext of denes a virtual repository as an aggregate of ollaborat-
the Customers diagram. The a quired properties dier from ing VOs (following [28℄ we ould say: parti ipant graph) in
one role to the other. Other properties are shared from the terms of an aggregate of ROs. By being a rst{ lass obje t
base obje t (e.g. the name). it an be applied dynami ally to perform tool integration,
hen e, the name dynami view onne tor.
A base obje t plays a given role always with respe t to a er-
tain ontext whi h omprises a set of ollaborating obje ts. CO
The idea is that the pro ess of reating a virtual repository
from the real repository model o urs not at the level of indi-
vidual lasses, but rather at the level of ollaborating lasses: CONNECTOR
When following the features asso iation of a CLASS RO as
seen from a Class VO, all rea hable ROUTINE ROs are impli -
itly adapted to Method VOs. Adaptation of rea hable ROs TOOL_A_CONNECTOR TOOL_B_CONNECTOR
to VOs of the orresponding roles is automated by the work- attribute1 : t1
ben h. In fa t, as we will see, both Class and Method will be method1(a :t2) : t3
TOOL_C_CONNECTOR
dened together as types parti ipating in the same higher{ VC1 VC3

level abstra tion, that of a UML CLASS DIAGRAM. Te hniques VC2 VC4
for grouping a graph of obje ts as adaptations of some base
graph of obje ts are being developed as Adaptive Plug&Play
Components [28℄ and Pluggable Composite Adapters [29℄. Figure 10: Hierar hy of onne tor lasses
With the virtual repository abstra tion being part of PIROL,
ea h tool is written as a self{ ontained omponent to its own 2.2 Mapping constructs
meta{model | its fun tionality is en oded in a set of ol- Like any Lua/P lass, onne tor lasses ontain feature deni-
laborations between the elements in its meta{model. The tions and may inherit from other onne tor lasses. Further-
latter is dened by a set of nested interfa es whi h is alled more, a onne tor lass nests a set of view lasses, one for
the expe ted interfa e of the tool. This denes the tool's ea h interfa e in the tool's expe ted interfa e. The lasses
\view" of the repository, or, alternatively, an \ideal" repos- CO and CONNECTOR are predened in the repository model
itory model tailored to the spe i needs of the tool. Fig. 9 with the onne tor inheritan e hierar hy as shown in Fig. 10.
shows part of a textual representation of the model in Fig. 4 6
The interfa e GRAPH introdu es some general abstra tions,
| this is the expe ted interfa e to whi h the UML{diagram that are used by lasses in UML CLASS DIAGRAM.

8
Conne tors supersede the on eptual obje ts mentioned in Conne tor GRAPH CONNECTOR
1
Se t. 1, so in the sequel the abbreviation CO is used for
f

onne tor obje t. 2 root = Node

3 lass Node
f
4 adds = fposition : Pointg
The onstru ts that make up a onne tor denition will be 5 g, 
illustrated by means of the example onne tor UML CLASS- 6 lass Edge
f
DIAGRAM CONNECTOR in Fig. 11, whi h implements the UML- 7 adds = fline : List(Point)gg,
8 g,
CLASS DIAGRAM tool model of Fig. 9 on top of the reposi-
9
tory model of Fig. 3. Within a Conne tor denition (10)7
g

10
Conne tor UML CLASS DIAGRAM CONNECTOR

there are ve onstru ts that dene stru ture and behav-
f

ior of the onne tor obje ts (beside those that dene view 11 inherit = GRAPH CONNECTOR,
12 attributes = f
lasses nested in the onne tor): inherit, attributes, meth- 13 system : SYSTEM,
14 g,
ods, reation and root. The keyword inherit serves to de- root = Pa kage
15
ne a new onne tor lass by inheriting from an existing 16 reation = onne t,
one, the same way, e.g., extends does for lasses in Java. 17 methods = f
For instan e, UML CLASS DIAGRAM CONNECTOR inherits from 18 onne t (root ro : SUBSYSTEM)
19 CONNECTOR: onne t(root ro)
GRAPH CONNECTOR (11) whi h provides abstra tions su h as 20
system = root ro:get system()
Node and Edge: a UML lass diagram is a tually a graph. 21 end
22 g, 
The keyword attributes serves to de lare attributes of on- 23 lass Pa kage
f ro lass = SUBSYSTEM,
ne tor instan es. Ea h instan e of the onne tor lass in 24 uses = f
Fig. 11, e.g., refers to the top{level SYSTEM RO (13) ontain- 25 lasses : List(GeneralClass),
ing the pa kage that is being shown in the UML diagram at 26 links : List(Link),
27 ndClass (name: String) : GeneralClass,
hand. Similarly, the keyword methods introdu es methods 28 g,
that an be applied to onne tor instan es. The reation 29 g,

lause is used to de lare the instantiation method for the 30
lass GeneralClass
f ro lass = CLASS,
onne tor (16), sin e Lua/P has no onstru tor naming on- 31 inherit = Node,
32 g,
vention a la Java. In our example, it is the onne t method 
(18) that should be alled in order to reate instan es of 33 lass ImportedClass
f
34 inherit = GeneralClass,
UML CLASS DIAGRAM CONNECTOR (the usage and implementa- 35 predi ate ()
tion of this method will be dis ussed in some more detail 36 return not o.root ro:eq(ro.subsystem)
in Se t. 2.3). The RO and VO aggregates that are mapped 37 end,
38 uses = f from : Pa kage = subsystem g
by a onne tor both have a designated root obje t whi h is 39 g,

known within a CO as root ro and root vo, resp. The type 40
lass Class
f
of the root VO is de lared in the root lause of a onne tor. 41 inherit = GeneralClass,
In Fig. 11, the root view lass is Pa kage (15). 42 predi ate ()
43 return o.root ro:eq(ro.subsystem)
44 end,
Conne tor{level denitions are followed by nested view lass 45 reation = fpla eg,
denitions. First, for ea h view lass VC used by the tool, the 46 uses = f abstra t = is deferred g,
47 adds = f shrink : Boolean g,
ro lass lause de lares the repository lass RC to whi h VC 48 lter = f
is mapped. For ea h instan e vo: VC, vo. o refers to the en- 49 attributes : List(Attribute) = f
50
base = ffeatures : List(FEATURE)g,
losing onne tor, while vo.ro refers to the repository obje t 51 predi ate (f : FEATURE)
ro: RC of whi h vo is a view within vo. o. Three onstru ts 52 return f: onforms("ENTITY")
(uses, lter and redire t) dene how virtual obje ts are on- 53 end
54 g,
stru ted out of the data stored in ROs. New attributes 55 methods : List(Method) = f
and/or methods of a view lass that have no orresponden e 56 base = ffeatures : List(FEATURE)g,
57 predi ate (f : FEATURE)
in the RO lass are dened within the adds onstru t. Map- 58 return f: onforms("ROUTINE")
pings as well as added attributes/methods are also inherited 59 end
from parent view lasses (possibly dened in a parent on- 60
g
61 g,
ne tor lass). For instan e, GeneralClass (30) inherits the 62 a ept ()
attribute position from Node in GRAPH CONNECTOR. 63 shrink = False
64 ro.subsystem = o.root ro
65 end
uses. This onstru t spe ies those features of a view lass 66 g, 
that are identied with features of the orresponding RO 67 lass Attribute
f ro lass = ENTITY,
lass. This lause may optionally rename the repository fea- 68 redire t = f type : String = f / see Fig. 12 / gg

ture and/or spe ify the view type to whi h the value of the 69 g 
feature ought to be onverted to. For illustration onsider 70
lass Method
f ro lass = ROUTINE
the uses lause in the denition of ImportedClass (38). It 71 adds = f body : String g
72 g 
spe ies that (a) the feature subsystem from the underlying 73 lass Link
f ro lass = RELATION,
RO lass CLASS ( f. Fig. 3) is visible in the ImportedClass 74 inherit = Edge,
view under the name from, and (b) when used in this on- 75 g
76 g
text the value of this feature is to be automati ally (by the
7
Throughout this subse tion, numbers in parentheses de- Figure 11: Conne tor for UML lass diagrams.
note line numbers in Fig. 11.

9
 :::
run{time ma hine) onverted to a VO of type Pa kage as 
lass Attribute
f
dened within the same onne tor. Details of onverting an ro lass = ENTITY,
RO to a VO (we also use the term lifting for this pro ess) redire t
 =f
will be given later in this se tion. Note that the uses de -  type
: String = f
laration for findClass in Pa kage (27) refers to a method get ()
that is adapted just like the attributes shown above: within return ro.type.name
end,
this onne tor the method result is assumed to be of type assign (value : String)
GeneralClass, that is, ea h resulting obje t is lifted to the lo al type
view lass GeneralClass. if value == "" then
ro.type = nil; return
end
adds. A view lass may introdu e new attributes that do not type = o.system:nd type(value)
if not type then
have ounterparts in the repository. E.g., attributes shrink error("Unknown type "..value)
(47) and position (from Node (4)) of Class, de lared using end
the adds keyword, do not relate to any attributes in the ro.type = type
end
repository model. g
g

lter. This onstru t may be applied to 1:n repository level

g
:::
asso iations (list{attributes), in order to produ e sele tive
views of a them. The repository list{attribute to be ltered
is spe ied by the keyword base. A predi ate fun tion deter- Figure 12: Manual redire tion of attribute type
mines the sele tion riterion. It is applied to ea h element of
base to de ide if it should be in luded in the orresponding RO will do perfe tly, as shown in the implementation of get
tool{spe i list{attribute. Elements of the base list that in Fig. 12. The other way around, translating a string rep-
pass the test are onverted to a view lass when in luded resentation of a type to a TYPE RO, when the user enters
into the resulting list. In Fig. 11, Class denes two sele - the type of an attribute via the UML diagram editor, is
tive views on the features attribute of CLASS. The lters more tri ky. It involves the system attribute of the en los-
attributes (49) and methods (55) split the base list at-
ing onne tor: the method find type of SYSTEM is invoked
tribute features a ording to the type of ea h element into to nd a TYPE RO whose name mat hes the string passed as
a list of ENTITIES that are lifted to Attributes and a list a parameter to assign. Another example for the usefulness
of ROUTINES that are lifted to Methods. of the redire t onstru t is when an asso iation between
two lasses in a onne tor should be mapped to a ompound
A predi ate may also be asso iated with a view lass. For in- path between lasses in the repository model.
stan e, both lasses Class and ImportedClass dene views
on the same RO lass CLASS. Whether instan es of CLASS
should be seen as Class, respe tively ImportedClass, de- 2.3 Repository, view, and connector objects
pends on the result of evaluating the respe tive lass predi- Fig. 13 illustrates the run{time stru ture of onne tor ob-
ates (35,42) at run{time. So, when reading a Pa kage's list je ts and the relationships between the involved VOs and
of lasses (25) within the ontext of a onne tor, ea h RO ROs, by the example of the UML CLASS DIAGRAM CONNECTOR
ontained in the base list attribute ( lasses of SUBSYSTEM instan e for the A ounting do ument in Fig. 8 (# o1). The
in Fig. 3) is examined with respe t to the predi ate of ea h f g f g
dependen ies labeled uses and lter illustrate, how val-
andidate view lass Class and ImportedClass. The view ues are shared between the involved VOs and their or-
lass whose predi ate fun tion returns true is hosen for lift- f g
responding ROs. The adds dependen y shows that the
ing8 . added attribute position is stored in the surrounding CO.

redire t. Any other mapping that annot be de laratively Let us now onsider how the relationships between ROs, VOs
expressed with the onstru ts dis ussed so far an be hand{ and COs, are established and maintained. Fig. 14 illustrates
oded by dening two fun tions: get and assign for reading, how root ROs enter a onne tor when the latter is reated.
respe tively writing the value of an attribute. For illustra- As dened in Fig. 11, onne t expe ts the root RO (in this
tion, re all the stru tural mismat h between the representa- ase of type SUBSYSTEM) to be passed as a parameter. In
tion of Attribute types in the graphi al editor | a String Fig. 14, we assume that s1 is the RO for the A ounting
| as opposed to the representation of FEATURE types in subsystem (#s1 in Fig. 13). The exe ution of the rst line
the repository | an instan e of the repository lass TYPE. in Fig. 14, will
The uses onstru t is of no help here. Sin e String is a (a) reate an instan e of UML CLASS DIAGRAM CONNECTOR
Java predened rather than a view type whose denition is (# o1 in Fig. 13),
available within the onne tor, the Lua/P VM has no idea of
how to onvert TYPE to String and ba k. The programmer (b) set the root ro of # o1 to #s1,
of the onne tor provides the VM with this knowledge by ( ) initialize the attributes of # o1 (e.g., the system is ini-
hand{ oding the onversion pro ess. When going from the tialized with the result of alling get system on #s1),
repository model to the tool model, the name of the TYPE (d) wrap #s1 into a Pa kage VO (#p1 in Fig. 13) and set
this VO to be the root vo of the onne tor (# o1).
8
For the time being, we restri t lass predi ates to be based
on onstant attributes only, although obje t migration, i.e.,
dynami ally hanging the type of an obje t, might be ome Of these steps, (b) is triggered by alling the inherited ver-
a relevant topi here. sion of onne t (line 19 in Fig. 11) and only ( ) is expli -

10
 #co1 : UML_CLASS_DIAGRAM_CONNECTOR CO
ROID property value
#ic2 position (10, 42) {adds}
...
#ic2:ImportedClass VO
root_vo #p1 : Package
position = (10, 42) #at1 : Attribute
classes attributes
name = "Accounting"
name = "Customer" name = "address"
co co co
ro ro ro
#s1 :SUBSYSTEM {uses} {filter} RO
#c1 :CLASS #e1 : ENTITY
{uses}
root_ro name = "Accounting" name = "Customer" name = "address"
... classes ... features ...

Figure 13: Run{time relations between ROs and VOs in a Conne tor.

itly spe ied by the programmer in the implementation of re urring patterns of mapping.

UML CLASS DIAGRAM CONNECTOR:: onne t. The rest is taken
are of by the Lua/P interpreter. First, the de larative style a hieved through high{level on-
stru ts improves the readability and maintainability of the
:::
o1 = UML CLASS DIAGRAM CONNECTOR: onne t(s1) onne tor ode. Without spe ialized onstru ts, onne tor
ed = Workben h:get tool for do ument type( o1. lass) lasses will very likely ontain a lot of stereotyped ode du-
ed:show( o1.root vo) pli ation and unne essarily in lude too mu h detail about
the repository model. This results in onne tors that are
:::

diÆ ult to read, evolve and maintain.

Figure 14: Conne tor instantiation
Se ond, using only redire t mappings ould severely impa t
In Fig. 14, #s1 enters a onne tor expli itly: this is the ase the performan e of the system. To understand why, one
with root ROs. Other ROs might enter a onne tor s ope has to re onsider hange propagation in the presen e of vir-
impli itly when they are rea hed via a referen e (from an- tual repositories. Before the introdu tion of VOs, every data
other already lifted RO) for whi h a view mapping is dened hange in the repository unambiguously on erned a single
in a uses or lter de laration. It is the type dened in this RO. Hen e, it was easy to deliver hange noti ations on
mapping (the de lared type of referen e ), that is used to au- the basis of ROs and their attributes. With VOs, it is, how-
tomati ally lift (wrap) an RO to a VO. ever, ommon that one atomi hange in the repository af-
fe ts several obje ts: one RO and all VOs that are views
When a VO omes into being, i.e., its base RO is lifted within of that RO. It is ru ial that VOs are also notied in order
a given onne tor for the rst time, its added attributes, if to preserve onsisten y between all do uments in the envi-
any, are still uninitialized. The a ept fun tion within the ronment. Change noti ations on erning VOs need to be
denition of a view lass initializes the added attributes of a generated automati ally just like for ROs to ensure that the
VO (see lines 62{65 in Fig. 11 for an example). Invoking a - dieren e between ROs and VOs remains transparent for the
ept is done automati ally by the Lua/P interpreter. A ept tools. They are implemented only against their expe ted
fun tions are written by the programmer just like reation interfa e from whi h proxy lasses are generated, without
methods/ onstru tors, with the only dieren e, that a ept knowing, whi h proxy obje ts stand for ROs and whi h for
operates on a VO whose used and ltered attributes are al- VOs. In fa t, only this seamless a ess of ROs and VOs |
ready available from the underlying RO and the referen es in luding hange propagation | enables us to use the term
ro and o have been set. Only the VO's added attributes virtual repository.
need to be initialized.
The dependen ies between ROs and VOs as established us-
The interpreter automati ally onverts a VO to an RO, | ing built{in mapping onstru ts are known to the work-
the lowering operation | every time a VO is passed out- ben h (the Lua/P VM): for ea h hanged RO, it knows ex-
side the ontext of a onne tor, e.g., as an argument to a a tly whi h attributes of whi h VOs need to be hanged
workben h request involving a dierent tool. A VO{to{RO and an broad ast this hange eÆ iently. This is not true
onversion is equivalent to evaluating the expression vo.ro. for hand{ oded mappings (using redire t). The dependen-
ies established by this kind of mapping relationship are en-
2.4 Hand coded mappings versus specialized oded in the programmers ode. This makes it hard for the
VM to determine when a hange in the repository should
constructs result in a mapped attribute to hange its value a ord-
As indi ated above, a tually any attribute mapping an be ingly. The re{ omputation of redire ted values is often trig-
expressed by the redire t onstru t. So, why do we then gered by \false alarm" be ause the interpreter la ks detailed
need the other onstru ts, uses, adds, lter besides the lass knowledge about the data dependen y. These ex essive re{
level mapping onstru ts ro lass and predi ate? There are omputations ause performan e penalties.
two main reasons for providing spe ialized onstru ts for

11
Providing predened spe ialized onstru ts always omes stubs for CORBA or ...
with the danger of arbitrariness. The question is how to expected interface (IDL) generate
dene a set of standard mappings independently of a parti -
ular appli ation, i.e., with enough expressive power to over PIROL proxies

the needs of most appli ations. A ombination of theoreti al program Dynamic View Connector
analysis and empiri al evaluation should eventually yield a repository model (Lua/P)
set of onstru ts that is satisfa tory for all relevant prob-
lems. While not apt for proving ompleteness in a rigorous
sense, a preliminary analysis [17℄ indi ates that the DVC Figure 15: Tasks of integrating a tool
mapping onstru ts presented here do over a wide range of
relevant situations.
liverable tool whi h should preferably be pre- ompiled and
For illustration, let us dis uss the overage of relevant situ- be pre-linked without an implementation of these interfa es.
ations that o ur when mapping RO lasses to VO lasses. The rst step in integrating su h a tool onsists in provid-
In [17℄, similar onsiderations are given for the mapping of ing a library of proxy lasses that en apsulate all persistent
instan es, attributes and lists. Three ases are trivial: 0 : n obje ts and in addition to delegating a ess requests from
(new lasses introdu ed in a onne tor), 1 : 1 (dire t map- the tool via middleware to the data storage, also allow to
ping, set equality) and n : 0 (no mapping for an RO lass). register observers for hange noti ations from the middle-
We also saw the 1 : n ase in the example. Class CLASS ware. This step an be automated by tools su h as an IDL
from the repository model is split into lasses Class and ompiler. Similarly, we will provide a generator for PIROL
ImportedClass, whi h is dis riminated by a lass predi ate proxies ( f. Fig. 15). Deploying a tool is then a matter of
(alternatively the de lared type of a referen e through whi h furnishing also the set of generated proxy lasses for the
an RO is rea hed might also de ide, whi h view lass to use hosen middleware.
for lifting).
The requirements so far implement what we all \physi al
pluggability". A tool that is developed a ording to these
In order to omplete this pi ture for lass mappings, the rules an be used with dierent implementations of mid-
only remaining situation is when several (unrelated) RO dleware (MSG or CORBA or : : : ) and thus with dierent
lasses, e.g., RC1 and RC2, are mapped to (merged into) repositories or other data{stores, provided the stru ture of
one virtual lass VC (n : 1 mapping). proxy lasses onforms to the on rete repository model,
This ase needs no spe ial syntax, sin e RC1
VC whi h is very unlikely. In order to re on ile logi al in om-
it an be implemented by one indire - patibilities between the stru ture of the proxy lasses and
tion: First, the repository lasses are RC2 the on rete repository model, the integration of tools now
mapped to orresponding view lasses VC1 in ludes an additional step. A dynami view onne tor has
(VC1, VC2). Then a supertype VC for VC2 to be developed ( f. Fig. 15), whi h is the only pla e in
both view lasses is introdu ed. View lasses VC1 and VC2 the system that knows about both the tool model and the
implement the interfa e of VC in terms of their repository repository model. The onne tor reates a spe ialized view
lasses RC1 and RC2. of the repository, or, a \virtual repository", making the tool
`believe' it would operate on a repository, whose s hema is
The mapping onstru ts implemented so far do not over, identi al to its expe ted interfa e. The tool will, however,
e.g., the ase when a whole path in the repository lass never see obje ts of the real repository model, but only vir-
graph (a derived asso iation between two repository lasses) tual obje ts, whi h simulate the expe ted stru ture and be-
is mapped to a dire t asso iation between to view lasses, havior on top of the repository model. Implementation of
or when an obje t is mapped to an atomi value. These are a dynami view onne tor requires hand rafting, but this
two examples where we would suggest the use of redire t. is onned to one module, and from todays experien e we
In ase ertain patterns of redire tion like that o ur over expe t this to be a task of low eort.
and over again, we might, however, onsider adding a new
keyword as a shorthand for su h stereotyped mappings in 3. EVALUATION
the future. Addressing the mapping of paths with expli it Our fo us has been mainly on high{level dimensions of on-
onstru ts is under onsideration for future extensions. This erns involved in the \appli ation logi " of an SEE: (1) the
would bring forward the benets of Adaptive Programming basi data abstra tions of the SEE (the repository) (2) the
[23℄ also for Lua/P. It would make onne tor ode more ro- features of an SEE (as represented by the tools), and (3)
bust w.r.t small stru tural hanges in the repository model. what we alled the logi al integration of on erns from the
above two dimensions. Other dimensions, that do not di-
2.5 Tool integration with DVCs re tly ontribute to the appli ation logi but rather dene
Finally, let us brie y summarize the tool integration pro- system properties, su h as transa tion management, on ur-
ess in the presen e of DVCs. As far as the tool denition ren y ontrol or distribution aspe ts, orthogonally apply to
is on erned, the requirement holds that the tool must be all elements of the workben h interfa e. Most on erns in
developed against an expe ted interfa e where some mid- these dimensions are already overed by the fun tionality of
dleware an be plugged in that en apsulates any underlying the underlying middleware or repository and were not ee -
data storage. Let us assume, that the interfa e of all persis- tively elaborated in this paper. We did, however, mention
tent obje ts (the tool model) is dened by means of CORBA two dimensions in the system properties ategory: (4) data
IDL or Java interfa es. These interfa es are part of the de- syn hronization (implemented by the hange propagation

12
me hanism) and (5) semanti al integrity of repository data. vi es (e.g., tool allba ks within the me hanism of hange
Data syn hronization in ludes on erns su h as triggering, propagation) and (3) a spe ial language onstru t (attribute
distributing and rea ting to hange noti ations. In the guards) to \de orate" the default semanti s of attribute a -
semanti al integrity dimension, we onsidered the on ern ess with additional behavior, as needed.
of maintaining onstraints over repository data by imple-
menting onstraint{preserving poli ies as attribute guards. Note, that the hoi e for (1) would hange if variability on-
Another on ern in this dimension is avoidan e of data re- erning the system ar hite ture were to be supported. An
dundan y, whi h is also an issue in PIROL, but falls beyond example of an alternative ar hite ture would be a \poor{
the s ope of this paper. man's" implementation, where the repository is repla ed by
plain le storage, all tools were integrated to a single pro ess
Using the dimensions (1 { 5) mentioned above as our \test and hange propagation had to be re-implemented by sim-
ben h", in this se tion we dis uss the design of PIROL along ple method invo ations instead of the server based message
the questions on erning the design spa e of MDSOC models dispat hing. If variability with regard to system ar hite -
posed in the introdu tory se tion. ture is needed, dispat hing hange noti ations would have
to be dened as an expli it on ern rather than a transpar-
Q1: Specialized language support ent system servi e, so that it an be repla ed by dierent
It appears that the standard obje t{oriented model together implementations appropriate for dierent ar hite tures. It
with a long{term ommitment to ar hite ture do a good job would be pure spe ulation, to elaborate on the language on-
in a hieving modularity in the denitions of separated on- stru ts, that would be needed in order to dene arbitrary
erns in the data and feature dimensions. Provided the pro- implementations for dispat hing noti ations. However, as
grammer of a tool agrees on (a) de laring the expe ted inter- long as this variability is not needed, a transparent imple-
fa e of the tool and (b) implementing the tool's fun tionality mentation of system properties an be given with less oding
to this interfa e, the tool an be written as a stand{alone eort and providing a better performan e than in the more
obje t{oriented appli ation. Similarly, the repository meta general ase.
model is written as a standard ( ertainly well{designed)
obje t{oriented program in Lua/P, isolated from all other Q2: Explicit integration
on erns. The designer of the meta{model only needs to In answering this question, one has to trade o understand-
fo us on the basi abstra tions involved in the pro ess of ability, exibility, reusability against performan e. Our ex-
software development. perien e shows that the integration of high{level on erns
that are involved with the appli ation logi should be de-
On the other hand, spe ial language support ( ombined with ned in expli it onstru ts, separately from the on ern def-
a ommitment to a well{dened system ar hite ture) omes initions. High{level on erns will very likely be subje t of
quite handy for separating on erns related to system prop- reuse and mixing their denition with integration issues hin-
erties. Consider e.g., hange propagation. Separating dif- ders their reusability.
ferent on erns of hange propagation from ea h other and
from the appli ation logi was a hieved by (a) having hange To support this laim, we presented two approa hes to the
noti ation as a built{in feature of the workben h and (b) by denition of the \logi al" integration between the ore di-
onforman e to the multi ast{based ar hite ture of PIROL. mensions: features and basi data abstra tions. In the rst
Triggering hange noti ations happens at the meta{level approa h, bridging data mismat hes during integration was
(within the Lua/P interpreter) orthogonally to appli ation mainly a matter of the adapter ode spread around the tool's
logi . The dispat hing of noti ations is the responsibility ode. There was no distin t, separable integration layer,
of the message hannel, implemented by a separate server with the reported negative impa t on maintainability. By
pro ess that is loosely oupled to its lients | the workben h extending Lua/P with DVCs, we separated the \logi al" inte-
and the tools | via the me hanism of message{pattern reg- gration from tool denition whi h improved omprehensibil-
istration. Tools dene their rea tion to hange noti ations ity, reuse, and maintainability. The additional adaptation
by means of allba ks registered with the messaging han- layer de ouples the repository and its tools in multiple ways.
nel. These are well{separated from other on erns, su h as First, the repository model may evolve without ae ting ex-
tool fun tionality or the denition of the repository data isting tools, whi h are prote ted against these hanges by
abstra tions. the onne tor. Only the onne tor needs to be hanged.
Se ond, tools may be enhan ed with no need to hange the
Maintaining the semanti al integrity of shared data also repository model, as long as other tools depend on the old
makes use of a spe ial onstru t of Lua/P, the attribute guards, model. Third, other tools may immediately benet from the
whi h allows the programmer to plug additional behavior enhan ed model by also using the new onne tor. Fourth,
into the meta{level semanti s of attribute a ess. Due to the same tool may be used to manipulate dierent types of
these built{in \hot spots", the integrity preservation on- obje ts: plugging a tool to a set of RO lasses, denes its
ern an be dened well separated from the appli ation{level semanti s in terms of the repository model. Dierent on-
ode in the poli ies asso iated with attribute guards. gurations of the same tool may be plugged in at dierent
spots of the repository model providing dierent semanti s.
So, based on an ar hite ture suitable for the given domain, Other ombinations of evolution and reuse an be thought
we enri hed the obje t{oriented model by (1) an infras- of. All this omes with little eort: with its mostly de lara-
tru ture of built{in system servi es, that transparently ap- tive style, the denition of a DVC will for most appli ations
ply to all requests to the workben h, (2) obje t{oriented be small and easy to read and maintain. The ode for a
te hniques for lling in the hot{spots in su h system ser- onne tor is a su in t spe i ation of the required adap-

13
tation. In fa t, the example presented in this paper is only obje ts are possible ways to redu e performan e penalties.
slightly modied from the result of a real ase study. We are
onvin ed that implementing a DVC is not mu h additional However, there is no doubt that in answering the question
eort after understanding the required mapping in the rst about binding time one often has to trade o exibility
pla e. against performan e. \Often" is to emphasize that in some
ases, there is no option, i.e., binding must be dynami . One
On the other hand, reusability is probably less an issue for a of the arguments for runtime binding is that tool{spe i
onsiderable number of system properties. In analogy to the data has to be represented as rst{ lass obje ts in order to
above s enario of a poor{man's version of PIROL, on ern enable exible binding ardinality, allowing attributes of an
reuse by expli it integration would imply to ex hange, e.g., obje t or graph of obje ts to appear simultaneously in dif-
the MSG{subsystem by a third party ommuni ation servi e ferent views with dierent values of the same property. As
without modifying any other on ern. This would have to be already pointed out in Se t. 1, with ompile{time weaving of
a hieved by an expli it gate{way between PIROL's ompo- all partial denitions into one whole, as in [34, 9℄, it would
nents and the new ommuni ation software. Obviously, this be e.g., impossible to have the same lass simultaneously
kind of exibility is even harder to a hieve than pluggability displayed in as many dierent positions, as there are UML
of tools. I.e., for ertain integral parts of the environment do uments on the display that ontain the lass.
transparent integration may be more suitable.
Another argument for dynami binding is dynami re- ong-
When introdu ing an expli it integration layer, s alability urability, whi h implies that a tool an be repla ed by an-
issues have to be onsidered, as well. The introdu tion other, or new tools an be integrated on{the{ y, i.e., with-
of DVCs in our ar hite ture only slightly ae ts s alabil- out re ompiling the repository. A third s enario, where dy-
ity. This is be ause of the three{tier ar hite ture, where the nami binding is needed, is for atta hing additional behavior
workben h de ouples the sessions of dierent users. Sin e to repository obje ts, whereby several variants of the ad-
DVCs live within a workben h, and not within the reposi- ditional behavior and the ability to dynami ally ex hange
tory, only the following issues have to be investigated with these variants should be supported. For instan e, we might
respe t to s alability: the number of DVC instan es within want to enhan e ertain ROs with the ability to write them-
one workben h, the number of ROs to be lifted to VOs within selves out into a le, supporting several dierent storing
a single operation (say: loading a diagram) and the om- formats and the ability to dynami ally hoose the format
plexity of omputations performed on a graph of VOs. Su h depending on the ontext of use.
performan e measurements are still to be arried out. How-
ever, the number of users is no issue for DVC s alability. If, however, exible binding ardinalities or dynami evolu-
tion are not an issue, stati binding may be preferable for the
Q3: Binding time sake of performan e. There are ertainly ases, where bind-
The high{level on erns are bound at run{time in the ur- ing tools at link{time would be exible enough, provided
rent design. A tool is bound to instan es in the repository that integration an still be performed without a ess to
by instantiating a onne tor and applying it to a root RO. the tool's sour e ode. Link{time binding ould be onsid-
The resulting graph of virtual obje ts is lazily generated on ered as an alternative to dynami binding for all those ases
demand. Of ourse, a onne tor denition must exist whi h where only one onne tor of ea h onne tor type would ever
mat hes the expe ted interfa e of a tool. But this denition be reated for a given graph of repository obje ts and also
an be added to the workben h at any time during a running obje ts are mapped only on a 1:1 basis. This ould be seen
proje t, whi h ould also be seen as a run{time integration as a performan e optimization of our model, but it may also
of a new type of virtual repository. bloat the underlying database. Obje t elds from all views
of all relevant tools would have to be allo ated for all ob-
The late binding of VOs to ROs is not paid for at the sour e je ts of a given type, even if most of these obje ts may never
ode level, be ause lifting of the sub{ omponents of a root a tually appear within ertain views of ertain tools.
ROs happens automati ally as they ome into the s ope of
a onne tor. That is, the programmer never has to expli - Q4: Binding granularity
itly all the lift fun tion. However, there will obviously be Our experien e with PIROL shows that it is important to
impa ts on performan e due to (a) run{time lifting and (b) support on ern binding at dierent levels: features, lasses,
the delegation from VOs to the appropriate ROs respe tively asso iations and even whole ollaborations of lasses. We
COs. Although we annot for the moment ba k our laims emphasize support for binding at the level of ollaborations
by empiri al measurements, we expe t delegation from a VO of lasses, sin e this has been ignored by most of the MD-
to the appropriate RO resp. CO to have little impa t on the SOC models so far. Before introdu ing DVCs, PIROL's de-
overall performan e, be ause this delegation is hardly more sign did not support binding at the level of a set of ollab-
then dereferen ing one link per a ess; the appropriate a - orating lasses. Our experien e taught us that supporting
ess strategy for ea h de lared feature is already determined this level is ru ial in real{life omplex systems. The idea
at load{time of a onne tor denition. This overhead an be is that within an integrated environment mapping dierent
ignored when ompared to the overhead due to inter{pro ess ontext spe i denitions to some shared abstra tions will
ommuni ation between tools and workben h. Dynami lift- very likely not happen at the level of isolated elements.
ing may be more expensive espe ially in those ases where
the hoi e of the appropriate virtual lass to use for lifting The adaptation pro ess has, in general, to satisfy onstraints
depends on run{time state of the repository obje t to be su h as \if the abstra tion A has to be adapted to a view{
lifted. Analyzing the onne tor stru ture and a hing lifted spe i denition A' then the abstra tion B asso iated with

14
A has to be adapted to a view{spe i denition B', with 3. provides spe ialized onstru ts for allowing the pro-
the A{B relation being mapped to some A'{B' relation". If grammer to in uen e the semanti s of the language,
there is no language support for gluing at the level of lass whi h ome handy for dening ertain on erns of the
graphs as provided by DVCs (and onne tors, respe tively system property dimension (e.g., attribute guards as
adapters in [28, 29℄), these onstraints have to be manually poli ies for semanti al data integrity), and
programmed mixed within the ode for the A{to{A', respe - 4. introdu es a high{level onstru t for the dimension of
tively B{to{B' mappings. This was basi ally the approa h in integrating the data and feature dimensions.
the rst design of PIROL, where ea h adapter obje t within a
tool implementation was responsible for triggering the adap- Thus, our approa h indeed ombines features from several
tation of all relevant parts of its tool obje t, on e the tool MDSOC models. With PCA and SOP approa hes it shares
obje t was adapted itself ( f. Se t. 1.3). This approa h is the expli it onstru ts for dening integration, as well as
error{prone, sin e there is no guarantee that onstraints are the use of the standard obje t-oriented model for the def-
properly maintained. Furthermore, the gluing ode be omes inition of high-level on erns. Additional onstru ts su h
tangled, hard to read and fragile with respe t to hanges in as guarded attributes resemble the advi e onstru t of As-
the stru tural relationships. pe tJ, while still other issues like hange propagation are
mainly solved by ar hite tural design. In order for su h a
With DVCs, a whole graph of mutually referring view lasses \supermarket" approa h (\buy what you need") to work,
is bound to a graph of mutually referring repository lasses. it is desirable to have (1) a ommon foundation of MDSOC
Of ourse, this mapping is dened in terms of mappings te hniques (probably based on a language meta{model as we
between the lower{level onstru ts. A onne tor instan e mentioned in our introdu tion), (2) a atalogue of questions
denes an en apsulation of an obje t graph ensuring that to guide the pro ess of sele ting MDSOC te hniques, (3) a
all obje ts rea hable within a onne tor are lifted to the ap- language framework whi h allows to exibly integrate the
propriate view lasses dened in the onne tor. In a similar sele ted te hniques into an operational programming infras-
vein, the advantages of supporting extension at the level of tru ture. At the experimental stage of applying MDSOC
mutually re ursive types, i.e., types that refer to ea h other, to PIROL, Lua/P (and its host language Lua [19℄) proved to
su h as A and B in previous paragraph, has been a knowl- be well suited for this kind of evolutionary domain{spe i
edged in [3℄. In [3℄ inheritan e is used as the extension me h- language extension. This is due to its dynami meta{level
anism for dening mutually re ursive extensions of the base features that they share with other dynami languages su h
types ( orresponding to A' and B' in our example s enario). a Smalltalk [11℄ or Self [50℄. We an envision toolkits for
The adaptation of repository lasses by view lasses a tu- modular language onstru tion, that provide the power of a
ally follows the same pattern, ex ept for using aggregation spe ialized ombination of MDSOC te hniques even to or-
rather than inheritan e as the omposition te hnique. dinary development proje ts.
Q5: Binding cardinality Another insight form our ase study that might be valuable
In our design binding ardinality is exible in that no restri - for the MDSOC ommunity on erns the issue of a distin-
tions exist on the number and type of onne tors instanti- guished \base" on ern. Currently, there is no agreement in
ated for the same or overlapping set of base ROs. For the re- the MDSOC ommunity, as whether there is a \base" on-
verse ase uniqueness is of ourse indispensable: ea h graph ern that plays a distinguished role for the omposition or
of VOs is uniquely bound to a graph of ROs. When fo using not. The Xerox PARC approa h to MDSOC [22℄ seems to
on the elements within a onne tor, the exibility is given favor the \base" on ern idea, while other approa hes [49,
for having one RO playing dierent roles even within the 29℄ tend to onsider all on erns as independent. As far as
same virtual repository. Flexible ardinalities were already our experien e with the design of PIROL tells, the answer
supported by the rst design of PIROL: on eptual obje ts seems to be in the middle. It appears that, at least in the
(COs) dened views, that ould be instantiated multiply for ontext of integrated environments based on the repository
the same or overlapping sets of base obje ts. This was, how- ar hite tural style, the data abstra tion dimension indeed
ever, la king an elegant and type safe en apsulation. plays a distinguished role. All other on erns in one way
or other relate to this dimension, but it is important that
Lessons learned other on erns an still be developed independently. It is
Within the given ontext of designing an integrated software again the DVC layer that makes expli it, by whi h mapping
engineering environment, we took a mixed approa h to MD- other on erns relate to the base dimension. Change propa-
SOC by ombining the advantages of (a) a well{designed gation, e.g., is oordinated at the level of RO attributes, but
ar hite ture for a generi \wiring" me hanism between dif- is automati ally mapped to the on erns of tools by DVCs.
ferent on erns involved in the environment with (b) the Our experien e also shows the advantages of expressing the
strength of a hybrid domain{spe i language, that \base" on ern in a domain{spe i language, whi h trans-
parently supports ertain (for the domain important) system
1. builds upon standard obje t oriented notions, properties as built{in features omplemented with expli it
2. supports ertain system properties ru ial for the do- support for expressing other system properties. This level
main transparently as built{in features, (e.g., persis- of spe ialized support is not needed for the implementation
ten e, data syn hronization), while providing some hot of tools as kind of \se ondary" on erns.
spots, where lient ode may plug into these system
servi es (e.g., allba ks for handling hange noti a- Finally, the improvement in modularity as introdu ed by
tions), DVCs gives an en ouraging example of how any omponent

15
based system an be built with two seemingly ontradi tory nitions (distin tion between ROs and COs), whi h multiply
goals re on iled: The exible de oupling of omponents to exist in mediators, without, however, sa ri ing tool inde-
be integrated a{posteriori and the tight integration of om- penden e as in [9℄, and (b) deals with datatype mismat hes
ponents that as an ensemble perform a omplex set of fun - (through the adapters) whi h are ompletely ignored in [48℄:
tionalities. their impli it invo ation me hanism requires that events and
methods asso iated with them onform on their signatures.
4. RELATED WORK
Resear h about integrating software engineering tools al- In the GoodStep proje t[12℄, O2 Views[43℄ was developed as
ways had a fo us on supporting multiple views. As an early an extension of the OODBMS O2 . Similar to our approa h,
example, Garlan's [9℄ basi views an in fa t be seen as an obje ts in a view may \inherit" features from their base
anti ipation of subje t{oriented programming: the a tual lass by delegation. Views are again lters on shared data,
model of a entral database is an automati merge of the re- whi h are in this ase expressed as database queries. How-
quired models of dierent tools. The me hanisms supported ever, a view annot add values, that are not present in the
by basi views orrespond to our uses and adds lauses. Ob- base (i.e., no s hema ombination). The extension (the set
je ts are always manipulated within the ontext of a given of ontained obje ts) of a view has to be re al ulated by
view. This, in a way, resembles our way to identify a virtual an expli it ommand and updating through a view is not
obje t as the pair (roid x oid), but Garlan's views are onsistently solved. It follows that obje ts in a view behave
only identied by the view type, sin e basi views annot be noti eably dierent from base obje ts and the generation
instantiated. With DVCs on the other hand, view instanti- of a \virtual base" (i.e., a real base as seen through a view)
ation is an essential te hnique. Furthermore, Garlan's dy- from a base remains a heavy weight operation that prohibits
nami views generalize over our lter onstru t, supporting ne grained integration. With its support for materializing
a universal query language, but these views are not updat- a virtual base, O2 Views aims at exible s hema evolution,
able, only the obje ts ontained in su h a view (obje ts of whi h has also been pursued in dierent proje ts for stepwise
some basi type) are updatable. Dynami view onne tors integration of new tools.
on the other hand are arefully designed to ensure that all
mappings are reversible yielding views that annot be dis- The OODBMS Obje tStore [33℄ allows to dene \transformer
tinguished from ollaborations of base obje ts. fun tions" for performing data modi ation in the ourse of
s hema evolution. These dire tly orrespond to the transfor-
The following two themes an also be found in many su - mations implemented with our a ept onstru t as a means
essor approa hes on erning repositories for SEEs: (a) the for lazily adapting obje ts to new types.
global s hema an be ombined from dierent partial s hema
denitions and (b) the view on whi h a tool operates is de- All these approa hes rely on the assumption, that at any
ned as some kind of lter on shared data. PCTE [37℄, the given point in time, there exists one global repository s hema
repository used in PIROL, allows a \s hema denition set" to as a union of all involved partial s hemas. Ea h obje t has
extend existing obje t types (a). Tool views are dened by exa tly one identity and the overall stru ture of all views
a \working s hema", that simply enumerates s hema def- is either identi al (PCTE) or diverging stru tures are gen-
inition sets, su h that only values (obje ts, links and at- erated as se ond{ lass entities, that are not fully updat-
tributes) dened in these denitions are visible to the tool able (O2 ). If tools are to be de oupled ompletely, as it is
(b). The latter te hnique has been used, e.g., to implement needed for a-posteriori integration, it is ne essary to allow
generi tools [5℄. These tools are ongured by providing mismat hing s hemas to exist simultaneously, whi h in turn
a working s hema (lter) and exploit meta data (i.e., type requires on{line bidire tional translation between dierent
information) for traversing and displaying the given view. stru tures. This is a major novelty of dynami view onne -
tors.
Sullivan and Notkin [48℄ very learly state the problems with
software evolution in an integrated environment. They show Also, most repository data models do not allow view obje ts
the short omings of three basi designs for integrated envi- of the same base obje t to have dierent values for a given
ronments: (a) employing expli it invo ations between in- property ( ontext dependent dupli ation of attributes). This
dependent tools, (b) employing impli it invo ation via an is needed, e.g., for atta hing dierent position values to a
event model, and ( ) providing an expli it omponent that base obje t that appears in dierent diagrams of the same
en apsulates the individual tools and realizes their integra- type. Surprisingly, already PCTE provides an elegant so-
tion relationships. Their approa h ombines the advantages lution to this. A diagram an be modeled as an obje t
of the se ond and third basi designs, in whi h (a) the inte- whose links to ontained symbols (base obje ts) an arry
gration relationship is modeled in an expli it unit, the medi- attributes that are spe i to a base obje t within the on-
ator, and (b) individual tools are onne ted to an integration text of a given diagram. Unfortunately, link attributes have
unit via impli it invo ation. The design of PIROL presented no dire t mapping to obje t oriented programming languages.
here an be seen as an important improvement on the medi- Thus, a tool implementor is again fa ed with the problem
ators approa h to integrated environments. In the rst de- of translating this information into the given programming
sign of PIROL presented in Se t. 1.2, it is the workben h that language. In fa t, link attributes serve as a low level imple-
plays the role of a mediator and implements the integration mentation te hnique for added attributes of VOs in PIROL.
relations between individual tools whi h ommuni ate with Consequently ombining the on ept of role obje ts with
the workben h via impli it invo ation. In fa t, even this rst repository views is a ontribution of dynami view onne -
design of PIROL is an improvement on mediators be ause it tors.
(a) allows tools to share single opies of overlapping de-

16
Finally, older approa hes like PCTE work on pure data ob- A key theme of the work des ribed in this paper is separa-
je ts. Dynami view onne tors naturally integrate methods tion of on erns to avoid software tangling. This is also the
into the on epts of views, roles and ollaborations. Not motivation behind both aspe t oriented programming [22℄
only an views a ess the methods of the repository model; and HyperSpa es [49℄. Our work developed spe ial{purpose
this also allows to implement ( ertain servi es of) tools in language te hnology for supporting separation of some on-
Lua/P, granting for exe ution in the workben h. Fun tions erns in SEEs, and applies it to the design of a real system.
implemented in Lua/P an be invoked by any tool in the en- Another ase study for separation of on erns an be found
vironment, and thus dire tly ontribute to the set of servi es in [20℄, where AOP is applied to the design of a web{based
whi h the workben h provides to all tools. learning system. Separating stru tural and behavioral as-
pe ts of an obje t{oriented system is the fo us of the adap-
More re ent work on SEEs pays less attention on view def- tive programming [23℄ approa h. The stati stru ture of a
initions, but aims at optimizing other aspe ts. Most im- system is dened in a lass di tionary | essentially a textual
portantly, performan e and reuse of existing (monolithi ) representation of the lass graph. The behavioral aspe ts
tools ( ommonly bringing their own data stores) has for ed are written in terms of so{ alled traversal strategy spe i-
many authors to ompromises regarding their initial on- ations | essentially su in t des riptions of paths in the
epts. E.g., Reiss [41℄ des ribes a system alled DESERT lass graph | and do not embed detailed knowledge about
with many ideas that are similar to PIROL. Yet, only two the stru ture. Behavior written in this way is more robust
fairly weak on epts are in luded for integrating tools with against stru tural hanges.
stru tural mismat hes : at the level of ontrol integration a
message mapper interprets simple rules of translating mes- Several works in the area of obje t{oriented language de-
sages. Translation only allows renaming and rearranging of sign on roles [13℄, omposition lters [1℄, ontext obje ts [44℄,
message arguments. Se ondly, for the sake of data integra- variation{oriented programming [27℄, et ., also propose lan-
tion, \virtual les" may be dened as a olle tion of \frag- guage support for separating the denition of dierent as-
ments" (identiable portions of les). In this on ept, data pe ts. However, they fo us on the separation of on erns at
integration is based on plain les ontaining sour e ode, the level of a single, isolated obje t, and ignore important
rather than on a repository with a ne{grained meta model. issues that need to be addressed when dealing with sets of
In sour e ode entri environments, a tight semanti al inte- ollaborating obje ts.
gration is mu h harder to a hieve a ross development phases
and notations. While approa hes that build on existing om- Garlan et al. [10℄ identify ategories of mismat hes that
plex tools provide a good amount of integrated fun tionality o ur when integrating omponents into a system. Their
to the developer, our approa h is more visionary, as it learly analysis of the \nature of onne tors" with sub-issue \data
denes the onditions, under whi h third party tools an be model" omes losest to this work. Their fo us is, however,
integrated mu h more eÆ iently in terms of (a) a greater mu h more te hni al: their example addresses the issue of
variety of tools that an be integrated (not only those, that inter language working, whi h is given for free in PIROL by
work on sour e ode les), (b) a loser (semanti al) integra- de oupling omponents by means of a language independent
tion a ross notations, and ( ) greater ease of integration by ommuni ation layer. The omponents that were integrated
means of a su in t onne tor spe i ation. in the Aesop system were generi omponents, so no on rete
data models, that had to be re on iled, existed.
Apart from resear h in the domain of SEEs, several general
purpose on epts have more or less in uen ed the develop- DeLine's exible pa kaging [6℄ separates a omponent ore
ment of dynami view onne tors. fun tionality from its intera tion with a ertain ar hite -
tural style or omponent interfa e standard (su h as pipes
Views as a on ept are also used in requirement analysis and lters, A tiveX, or relational databases) within a er-
methods. For instan e, in [32℄ ViewPoints are used to model tain ontext of use into two separate modules: the ware,
dierent analysis artifa ts, ea h spe ifying partial require- respe tively the pa kaging des ription. Flexible pa kaging
ments for a system to be developed. ViewPoints also in- helps to automate the build pro ess of integrated ompo-
lude so{ alled inter{ViewPoint rules expressing the rela- nents in luding all supplementary resour es needed for this
tionships between separated requirement sli es. These rules purpose. DeLine's wares and pa kaging des ription roughly
are he ked for onsisten y during the integration phase and orrespond to tools, respe tively repository meta model in
eventually a transformation is performed to handle in onsis- PIROL with the meta model seen as one parti ular pa kaging
ten ies. This transformation has the avor of DVCs but the des ription for the underlying PCTE. DeLine also re ognizes
purposes are quite dierent: onsisten y he king of partial that name, datatype, order, and aggregation mismat hes be-
overlapping requirements versus integration of independent tween the pa kager and the ware should be dealt with and
omponents. exploits expli it maps for this purpose. Yet, the mapping
language is very primitive in luding, roughly speaking, only
The work on ollaboration{based design [18, 51, 46, 28℄ fo- a restri ted version of our redire t onstru t for primitive
uses on developing language support for dening ollabora- data types. Bidire tional onversions are not overed, nor
tions between several obje ts separately of the stati obje t are aggregation mismat hes, i.e., mismat hes on erning the
model of the system. Our work is related to this resear h in stru ture of data. Automati onversion of graphs of user
that we allow tools | whi h an be seen as large{s ale ol- dened data types are not supported at all. That is, as om-
laborations | to be written separately of the stati stru ture pared to the su in t and de larative nature of DVCs map-
of the repository obje ts that are involved in the ollabora- ping in the exible pa kaging approa h is \manual", whi h
tion. might turn out to be a tedious and and hard to get right job

17
in a real{life setting. Another dieren e on erns binding 7. REFERENCES
time. In the exible pa kaging approa h x-up ode from [1℄ M. Aksit, K. Wakita, J. Bos h, L. Bergmans, and
maps is inlined at ompile{time. As the result, only a 1:1 A. Yonezawa. Abstra ting Obje t Intera tions using
binding ardinality is possible. Composition-Filters. In Obje t-Based Distributed Pro-
essing, LNCS 791, pp. 152{184, 1993.
There is an analogy between DVCs and the use of deploy-
ment tools to map obje t (bean) attributes to data in a (rela- [2℄ K. Arnold and J. Gosling. The Java Programming Lan-
tional or obje t) database in the EJB omponent model [30℄. guage. Addison Wesley, 1997.
Due to the expli it deployment pro ess, a bean's denition
ontains only the business logi , free of integration issues, [3℄ Kim B. Bru e, Martin Odersky, and Philip Wadler.
and an for this reason be reused with dierent databases. A stati ally safe alternative to virtual types. In Eu-
This is similar to the de oupling of tool denitions from the ropean Conferen e on Obje t-Oriented Programming
repository model a hieved with the introdu tion of DVCs, (ECOOP), Brussels, July 1998.
prote ting tools against hanges in the repository. DVCs are [4℄ Clemens Czyperski. Component Software, Beyond
higher{level and allow for de larative spe i ation of more Obje t-Oriented Programming. Addison-Wesley, 1998.
omplex mappings. Furthermore, by being rst{ lass enti-
ties, DVCs an be reused with dierent versions of the same [5℄ D. Daberitz and U. Kelter. Rapid Prototyping of
tool or even with dierent tools, eventually by being layered Graphi al Editors in an open SEE. In Pro . of
on top of ea h other. 7th Conferen e on Software Engineering Environments
(SEE`95), pp. 61{72. IEEE Computer So iety Press,
1995.
5. SUMMARY AND FUTURE WORK [6℄ R. DeLine. Avoiding Pa kaging Mismat h with Flexi-
ble Pa kaging. In Pro eedings of the 21st International
In this paper we presented our experien e with applying Conferen e on Software Engineering (ICSE '99), 1999.
multidimensional separation of on erns to a software engi-
neering environment. The main fo us of the paper was on [7℄ E. W. Dijkstra. A Dis ipline of Programming. Prenti e-
requirements that this domain poses on the design spa e of Hall, 1976.
models for MDSOC. By omparing two dierent designs of
our system, we showed the importan e of separating integra- [8℄ E. Gamma, R. Helm, R. Johnson, and J. Vlissides. De-
tion issues from the implementation of the individual on- sign Patterns - Elements of Reusable Obje t-Oriented
erns. We presented a model in whi h integration issues are Software. Addison Wesley, 1995.
en apsulated into rst{ lass onne tor obje ts and indi ated [9℄ D. Garlan. Views for Tools in Integrated Environments.
how this fa ilitates the understandability, maintenan e and PhD Thesis, Carnegie Mellon University, May 1987.
evolution of the system. Furthermore, we identied as ru-
ial features for SEEs: (a) the postponement of the binding [10℄ D. Garlan, R. Allen, and J. O kerbloom. Ar hite tural
time of on erns until runtime | made possible by having Mismat h, or, Why it's Hard to Build Systems out of
onne tors as rst{ lass obje ts, (b) supporting the binding Existing Parts. In Pro eedings of the 17th Internation
granularity of on erns at the level of ollaborating obje ts, Conferen e on Software Engineering (ICSE '95), pp.
and ( ) enabling exible binding ardinalities with no re- 179{185, April 1995.
stri tions on the number of onne tors instantiated for the
same or overlapping sets of obje ts. These features en- [11℄ A. Goldberg and D. Robson. Smalltalk 80: The Lan-
able exible ongurability of SEEs in luding distribution guage and its Implementation. Addison-Wesley, 1983.
a ross ma hine boundaries and a-posteriori integration of [12℄ The GoodStep Team. The GOODSTEP Proje t: Gen-
third party tools without sour e ode modi ations. eral Obje t-Oriented Database for Software Engineer-
ing Pro esses. In Pro . of the 1st Asian Pa i Software
In the future, it would be interesting to explore more om- Engineering Conf, pp. 10{19. IEEE Computer So iety
plex situations of mismat hes in models, in order to gain Press, 1994.
a better understanding of what annot be bridged by our
onne tors and extend the usefulness of dynami view on- [13℄ G. Gottlob, M. S hre , and B. Roe k. Extending
ne tors towards even more omplex situations. This may Obje t-Oriented Systems with Roles. ACM Transa -
eventually lead to additional mapping onstru ts, of whi h tions on Information Systems, 14(3):268{296, 1996.
the mapping of paths a la AP has already been mentioned.
Furthermore, we plan to generalize over dierent te hniques [14℄ B. Groth, S. Herrmann, S. Jahni hen, and W. Ko h.
for \physi al pluggability" (i.e., middleware like CORBA), Proje t Integrating Referen e Obje t Library (PIROL):
in order to show how the on ept of \logi al pluggability" An Obje t{Oriented Multiple{View SEE. In Pro . of
an also be applied to these te hniques, in order to obtain a 7th Conferen e on Software Engineering Environments
fully pluggable omponent infrastru ture. (SEE `95), pp. 184{193, IEEE Computer So iety Press,
Apr. 1995.
[15℄ W. Harrison and H. Ossher. Subje t-Oriented Pro-
gramming: a Critique of Pure Obje ts. In Pro eedings
6. ACKNOWLEDGMENTS of ACM Conferen e on Obje t-Oriented Programming,
The authors would like to thank the anonymous reviewers Systems, Languages, and Appli ations (OOPSLA '93),
for their very helpful omments. Sigplan Noti es 28(10), pp. 411{428, 1993.

18
[16℄ S. Herrmann. Lua/P { A Repository Language for Flex- [30℄ R. Monson-Haefel. Enterprise Java Beans. O'Reilly &
ible Software Engineering Environments. In Pro . of Asso iates, In , 1999.
The Se ond International Symposium on Constru ting
Software Engineering Tools, pp. 78{86, ISBN 0 86418 [31℄ A. Nordwig. Entwi klung einer Notation und eines
725 4, 2000. gras hen Editors fur den objektorientierten Entwurf
hybrider Systeme. Master's Thesis, TU Berlin, 1997.
[17℄ S. Herrmann and M. Mezini.Dynami View Conne tors,
http://pirol. s.tu-berlin.de/papers/DVC.pdf, [32℄ B. Nuseibeh, J. Kramer, and A. Finkelstein. A Frame-
Te hni al Report, Te hni al University of Berlin, 2000. work for Expressing the Relationships Between Multi-
ple Views in Requirements Spe i ation. IEEE Trans-
[18℄ I. Holland. The Design and Representation of Obje t- a tions on Software Engineering, 20(10):760{773, O t.
Oriented Components. PhD Thesis, Northeastern Uni- 1994.
versity, Computer S ien e, 1993.
[33℄ Obje t Design, In , Burlington, MA. Obje tStore Ad-
[19℄ R. Ierusalims hy, L. H. de Figueiredo, and W. Ce- van ed C++ API User Guide, Mar h 1998.
les, \Lua|an extensible extension language," Software:
Pra ti e and Experien e, 26(6):635{652, 1996. [34℄ H. Ossher, M. Kaplan, A. Katz, W. Harrison, and
V. Kruskal. Spe ifying Subje t-Oriented Composition.
[20℄ M. Kersten and G. Murphy. Atlas: A Case Study in Theory and Pra ti e of Obje t Systems, 2(3):179{202,
Building a Web-Based Learning Environment Using 1996.
Aspe t-Oriented Programming. In Proeedings of ACM
Conferen e on Obje t-Oriented Programming, Systems, [35℄ PARC Xerox, available from http://aspe tj.org. As-
Languages, and Appli ations (OOPSLA'99), Sigplan pe tJ Language Spe i ation, Aug 1999.
Noti es 34(10):340{352, 1999.
[36℄ D. L. Parnas. On the Criteria to be Used in De ompos-
[21℄ G. Ki zales, J. des Rivieres, and D. G. Bobrow. The ing Systems in Modules. Communi ations of the ACM,
Art of the Metaobje t Proto ol. The MIT Press, 1991. 15(12), 1972.
[22℄ G. Ki zales, J. Lamping, A. Mendhekar, C. Maeda, [37℄ ISO/IEC 13719-1: Portable Common Tool Environ-
C.V. Lopes, J.M. Loingtier, and J. Irwin. Aspe t ment (PCTE). Abstra t Spe i ation, International
Oriented Programming. In Pro eedings of European Organization for Standardization (ISO), 1995.
Conferen e on Obje t-Oriented Programming (ECOOP
`97), LNCS 1241, pp. 220{243, 1997. [38℄ PIROL Web-page. http://pirol. s.tu-berlin.de.
[23℄ K. Lieberherr. Adaptive Programming: the Demeter [39℄ T. Reenskaug, E. P. Andersen, A. J. Berre, A. Hurlen,
Method. PWS Publishing Company, 1996. A. Landmark, O. A. Lehne, E. Nordhagen, E. Ness-
Ulseth, G. Oftedal, A. L. Skaar, and P. Stenslet.
[24℄ C. Lopes. D: A Language Framework for Distributed OORASS: Seamless Support for the Creation and
Programming. PhD Thesis, Northeastern University, Maintenan e of Obje t Oriented Systems. Journal of
Computer S ien e, Nov. 1997. Obje t-Oriented Programming, O t. 1992.
[25℄ P. Maes. Con epts and Experiments in Computa- [40℄ S. P. Reiss. Conne ting Tools Using Message Passing
tional Re e tion. In Pro eedings of ACM Conferen e in the FIELD Environment. IEEE Software, 7(4):57{
on Obje t-Oriented Programming, Systems, Languages, 66, July 1990.
and Appli ations (OOPSLA '87), Sigplan Noti es,
22(12):147{155, 1987. [41℄ S. P. Reiss. The Desert Environment. ACM Trans-
a tions on Software Engineering and Methodology,
[26℄ J. M Aer. Meta-Level Programming with Coda. In 8(4):297{342, O t. 1999.
Pro eedings of European Conferen e on Obje t-Oriented
Programming (ECOOP '95), LNCS 952, pp. 190{241, [42℄ J. Ri hardson and P. S hwarz. Aspe ts: Extending Ob-
Springer Verlag, 1995. je ts to Support Multiple, Independent Roles. In Pro-
eedings of the 1991 ACM SIGMOD International Con-
[27℄ M. Mezini. Variational Obje t-Oriented Programming feren e on Management of Data, 1991.
Beyond Classes and Inheritan e. Kluwer A ademi
Publisher, 1998. [43℄ C. Santos, S. Delobel, and S. Abiteboul. Virtual
S hemas and Bases. In Pro eedings of the International
[28℄ M. Mezini and K. Lieberherr. Adaptive Plug-and-Play Conferen e on Extending Database Te hnology, LNCS
Components for evolutionary software development. In 779, 1994.
Pro eedings of ACM Conferen e on Obje t-Oriented
Programming, Systems, Languages, and Appli ations [44℄ L. Seiter, J. Palsberg, and K. Lieberherr. Evolution of
(OOPSLA '98), Sigplan Noti es, 33(10):97{116, 1998. Obje t Behavior using Context Relations. IEEE Trans-
a tions on Software Engineering, 24(1):79{92, Jan.
[29℄ M. Mezini, L. Seiter, and K. Lieberherr. Component 1998.
Integration with Pluggable Composite Adapters. In M.
Aksit (ed.) Software Ar hite ture and Component Te h- [45℄ M. Shaw and D. Garlan. Software Ar hite ture: Per-
nology: State of the Art in Resear h and Industry, spe tives of an Emerging Dis ipline. Prenti e Hall,
Kluwer A ademi Publishers, 2000. 1996.

19
 [46℄ Y. Smaragdakis and D. Batory. Implementing Layered [50℄ D. Ungar and R. Smith. Self: The power of simpli ity.
Designs with Mixin Layers. In Pro eedings of European In Pro eedings of ACM Conferen e on Obje t-Oriented
Conferen e on Obje t-Oriented Programming (ECOOP Programming, Systems, Languages, and Appli ations
'98), LNCS 1445, pp. 550{570, Springer Verlag, 1998. (OOPSLA '87), Sigplan Noti es, 22(12):227{242, 1987.
[47℄ M. Stek, D. Bobrow, and K. Kahn. Integrating A ess- [51℄ M. VanHilst and D. Notkin. Using Role Components
Oriented Programming into a Multiparadigm Environ- to Implement Collaboration-Based Designs. In Pro eed-
ment. IEEE Software, 3(1):10{18, Jan. 1986. ings of ACM Conferen e on Obje t-Oriented Program-
ming, Systems, Languages, and Appli ations (OOPSLA
[48℄ K. Sullivan and D. Notkin. Re on iling Environment '96), Sigplan Noti es, 31(10):359{369, 1996.
Integration and Software Evolution. ACM Transa tions
on Software Engineering and Methodology, 1(3):229{ [52℄ R.J. Wieringa and W. de Jonge. Obje t Identiers,
268, 1992. Keys, and Surrogates. Theory and Pra ti e of Obje t
Systems, 1(2):101{114, 1995.
[49℄ P. Tarr, H. Ossher, W. Harrison, and S. Sutton Jr. N
degrees of Separation: Multi-Dimensional Separation
of Con erns. In Pro eedings of the 21st International
Conferen e on Software Engineering (ICSE '99), 1999.

20

View publication stats