[Prev][Next][Index]

Re: Larch and Reverse Engineering

Doug,

My apologies for the delay in answering your message.  I was out of town
last week, attending the conference on Foundations of Software Engineering
in New Orleans, and I'm just beginning to catch up on my e-mail.

The short answer to your question is that the methodology you would like to
use is at odds with the one we had in mind when we designed Larch.  This
does not mean that there is nothing in Larch that you can use, but that you
should not expect to find ready-made solutions to all your problems.

The Larch interface languages designed to date have been intended for
writing specifications such that the specification of each interface is
independent, so it can be written and studied independently.  The price we
pay is that an interface specification cannot incorporate another interface
specification "by reference."  I can offer some justifications for this,
but they may or may not apply to your intended use:

- Independence contributes to modularity.

- It allows the implementation more freedom, since it specifies only the
properties of the interface, not what must happen on lower levels of
abstraction within the implementation.  (I.e., we think that it is a
mistake to specify that a result must be obtained by calling a particular
procedure.)

- The right thing to share is *theories*.  The Larch Shared Language
already provides mechanisms for doing this.

What does a Larch interface specification specify?  The behavior of an
interface, in terms of a particular programming language.  In the language
of [1] and [2], it is a "local specification," that is, a language-oriented
behavioral specification of a single program unit.  It sounds like you are
looking for techniques for writing "system specifications" (i.e.,
application-oriented behavioral specifications of collections of programs
expressing constraints on systems in terms of what can be observed by its
users), and/or "organizational specifications" (i.e., structural system
specifications plus behavioral specifications of components).  These are
different, important, hard problems.

Of course, the boundaries are not quite so strict as this might suggest.
A specification for the procedure "Main" might describe the input/output
behavior of an entire application.  But the "design center" is quite
different.

Hope this helps to clarify things for you.

Jim H.

[1] "Some Notes on Putting Formal Specifications to Productive Use,"
SCIENCE OF COMPUTER PROGRAMMING 2 (1982) 53-68.

[2] "The Larch Family of Specification Languages," IEEE SOFTWARE, 2, 5
(Sept. 1985), 24-36.