Edit, Compile, Debug – From Hacking to Distributed Engineering

Christian Nentwich, Wolfgang Emmerich and Anthony Finkelstein

Department of Computer Science
University College London, London WC1E 6BT
{c.nentwich,w.emmerich,a.finkelstein}@cs.ucl.ac.uk

1 Background [3] we describe the application of xlinkit to checking the

consistency of the design, implementation, and deploy-
ment descriptors of Enterprise JavaBeans (EJB)-based
Specifying a system from different viewpoints, in het- systems.
erogeneous design notations, and using a distributed
team, introduces several challenges that test the state Consistency is defined in xlinkit through a set of con-
of the art in software engineering. One of these chal- straints, called consistency rules. A consistency rule
lenges is to check the consistency of such heterogeneous defines how elements in different documents are inter-
notations, and to deal with the problem of inconsistency related. Figure 1 gives an example of a consistency rule
throughout the lifecycle — including the management (using xlinkit’s XML rule syntax) that prescribes that
of inconsistency between notations at the same stages interfaces that inherit from “EJBObject” must be im-
of the lifecycle, such as multiple UML models, and in- plemented by a class that inherits from “EntityBean”
consistency between stages, such as the consistency of or “SessionBean”.
design and code.
xlinkit returns as its output a set of links that connect
We envisage a scenario where developers can execute inconsistent elements in document. This is an improve-
consistency checks at arbitrary stages of the lifecycle in ment on the boolean evaluation of first order formulae
order to get feedback. Developers are presented with because the links pinpoint precisely the combination of
reports on the current consistency status, and can de- elements that causes the inconsistency. Figure 2 shows
cide whether or not to take action. Because of the de- a link generated by evaluating the sample rule. In this
synchronised nature of distributed software engineering, case, the link points to only one location, the interface
we take a lightweight approach that does not require to- for which no corresponding class was found.
tal consistency, but instead fetches specifications when
developers are prepared to evaluate consistency, and
points out inconsistencies without forcing changes.
3 Consistency Management
Our most recent work is aimed at providing developers
with a range of choices for repairing documents, and
at addressing problems of scalability in checking dis- Consistency management, the problem of detecting, as-
tributed documents. sessing and potentially resolving inconsistency, is a deli-
cate topic that is subject to a variety of influences, from
domain specific ways of accomplishing goals, down to
individual working preferences. Having provided a so-
2 Consistency Checking phisticated system for detecting inconsistency, our goal
is to specify a very basic, rudimentary mechanism for
reporting inconsistencies and for making simple changes
To support the kind of activity outlined above we have in order to remove inconsistencies. Once such a basic
developed xlinkit [2], a generic technology for check- mechanism is in place, it can form the infrastructure for
ing the consistency of distributed, heterogeneous docu- a more elaborate consistency management or conflict
ments. xlinkit is a fully implemented, working system resolution process that can take into account informa-
that has been used in several industrial case studies and tion such as workflow, or policies that set priorities for
can be downloaded at http://www.xlinkit.com. different kinds of specifications to enable overriding.
While xlinkit can be used in many application domains, On a very abstract level, we expect a consistency man-
it is very suited to software engineering documents. In

1
 <forall var="i" in="/java/interface[extends/@name=’EJBObject’]">
<exists var="c" in="/java/class[../package/@name=$i/../package/@name
and (implements/@name=’EntityBean’ or
implements/@name=’SessionBean’)]"/>
</forall>

Figure 1: Sample xlinkit consistency rule

<xlinkit:ConsistencyLink ruleid="javaejb_inter.xml#id(’r2’)">
<xlinkit:State>inconsistent</xlinkit:State>
<xlinkit:Locator
xlink:href="Job.java#/java/interface"/>
</xlinkit:LinkBase>

Figure 2: Sample consistency link

5 Repair
Check

When elements in distributed specifications have been

Edit linked and identified as inconsistent, it should be possi-
ble to offer some simple repair choices to developers. As
Report an example, in our sample rule given above we have an
inconsistency because for some Java interface we did not
find a correct implementation. In this case, we could of-
Repair fer the developer to automatically introduce a new Java
class that fulfills the requirements.

Figure 3: Consistency management process In general, it is straightforward to enumerate the repair

options available to developers. One case add elements
to specifications, delete elements, and change proper-
agement process to look like Figure 3. Developers will
ties of elements. When adding or changing elements,
decide to assess the consistency of their documents,
one can let developers enter values for the properties of
make a check, get reports back, and either decide on
elements, search the specifications for existing values to
an action for “repairing” the documents, or defer the
use, or fall back to defaults.
decision and go back to editing. We have already ad-
dressed the checking process, and will concentrate on The challenging task is then not to enumerate repair
report generation and repair in the next two sections. options but to prune them in order to leave only “sen-
sible” choices. In our sample rule, we could remove
the inconsistency by deleting the offending Java inter-
4 Report Generation face — although in most cases this would be attacking
the symptom instead of the problem, and would not
be a sensible choice. We believe that the developers
xlinkit’s linking diagnostics, which connect inconsistent responsible for establishing the constraints should be
elements in distributed specifications and deliver them able to determine which repair actions make no sense.
in the form of an XLink [1] linkbase, are powerful but We are planning to analyse the formulae so as to come
not particularly friendly for human consumption. We up with an exhaustive list of actions and presenting a
have developed a report generation tool, Pulitzer, that simple interface for pruning them down.
can read such linkbases and display marked up infor-
mation about the elements that the locators point to. Should this kind of pruning process still result in an
overwhelming number of repair choices, domain specific
Using Pulitzer it is possible to provide reports similar heuristics can be used to cut them down further. For
to traditional compiler error output — but at the inter- example, it may be possible in a software engineering
viewpoint level! — in a variety of formats. Figure 4 setting to use a “differential” approach that compares
shows an HTML report generated after checking an EJB the consistency status of specifications before and after
system. the last consistency check, and uses this information to
determine more precisely which elements may have to

2
 Figure 4: Sample report

be changed. Whether this approach works or not, by 7 Conclusion

providing an enumeration of the repair choices based on
formula analysis, we will establish a sound infrastruc-
ture on top of which such heuristics can be built. We have outlined our current position with regard to
achieving a system for managing the consistency of dis-
tributed specifications. xlinkit takes a big step in this
direction by providing a solid base for checking the con-
6 Scalability sistency of distributed, heterogeneous documents.

We are now working to establish a simple method for

Scalability problems occur in various guises in consis- suggesting repair options to developers, without com-
tency management. A good system must be able to promising our view of inconsistency as something that
scale as the number of documents and constraints in- cannot necessarily be eliminated. We are also evaluat-
creases, and as the size of documents increases. It must ing our tools for dealing with scalability problems that
also be scalable in terms of user-friendliness, by provid- arise as documents sizes and the number of documents
ing mechanisms that simplify the expression of a large grow.
number of constraints.

We are currently working to address the problems of

checking large documents and large numbers of doc- References
uments through a variety of means: by providing in-
cremental checks, which analyse changes to documents [1] S. DeRose, E. Maler, and D. Orchard. XML Linking
and minimize the number of constraints that have to be Language (XLink) Version 1.0. W3C Recommen-
rechecked; by implementing a distributed supervisor – dation http://www.w3.org/TR/xlink/, World Wide
worker architecture that can deal with large amounts of Web Consortium, June 2001.
data; and by using the caching facilities of native XML
databases to lower the main memory requirements of [2] C. Nentwich, L. Capra, W. Emmerich, and
our service. Substantial progress has been made in these A. Finkelstein. xlinkit: a Consistency Checking and
areas. Smart Link Generation Service. ACM Transactions
on Internet Technology, 2001. To appear.
We have also implemented a macro mechanism and a
predicate plugin mechanism for our formula language [3] C. Nentwich, W. Emmerich, and A. Finkelstein.
that greatly facilitate the expression of a large number Flexible Consistency Checking. Research note, Uni-
of constraints. We are currently evaluating these fea- versity College London, Dept. of Computer Science,
tures in case studies. 2001. Submitted for Publication.