Interaction Contract

[o***@gmail.com]

Hi,

I'm working on my MS thesis titled "Interaction Contracts
in distributed systems". The aim of the thesis is to propose an
augmentation of "Design by Contract" paradigm with another level of
specifications called as Interaction Contract. Interaction Contract
will
explicitly and formally state the correspondence between methods
supported
by different components. These relationships are usually given
implicitly,
either in the code or in textual comments. Thesis will also describe a
notion of "Interaction Compatibility", giving a more reliable match
than
just type compatibility alone. Thesis will also describe a method to
semi-automatically generate Glue in case two components are not
Interaction Compatible. This will facilitate seamless component
composition.

The four levels of contracts viz. syntactic, semantic, synchronization
and
quantitative are inadequate because often there are rules constraining
the
order in which messages may be sent between two interacting components.
We
assume that these messages represent the invocation of methods given in
component interface. In other words, real word components often impose
a
restriction on the order in which methods supported by them can be
invoked. For example, consider a component which handles a file
system. For such a component, a file_open method call must precede a
file_read method call. It is difficult to formally document such
constraints relating the two components by using four levels of
contracts
mentioned above.

I was wondering if there is any literacture / research work available
for this purpose which I can use as a reference. Also any suggestions /
help will be greatly appreciated.

Thanks and regards

--- Omkar Tilak

[Patrick Eugster]

Omkar,

your thesis proposal looks very interesting to me. I share the opinion
that more than the traditional contracts could be added to the
specification of components, e.g., for security.

Regarding the example that you point out, people in the DbC community
would surely find a way of expressing such a constraint. But having
worked on these things in the context of the Eiffel programming language
and its concurrency model ("SCOOP"
http://se.inf.ethz.ch/research/scoop.html) I agree that there are
issues. Interestingly, some of the main players behind axiomatic
semantics and the foundations for contracts has somewhat turned their
backs on contracts in the context of concurrency. Besides the lack for
explicit specification of temporal aspects (e.g., file open has to
happen before read) with respect to a single object/server, there are
namely further problems with concurrent accesses, which might in fact
require class-spanning invariants.

Readings might thus also include work on temporal logic.

Best

Patrick Eugster

Post by o***@gmail.com
Hi,
I'm working on my MS thesis titled "Interaction Contracts
in distributed systems". The aim of the thesis is to propose an
augmentation of "Design by Contract" paradigm with another level of
specifications called as Interaction Contract. Interaction Contract
will
explicitly and formally state the correspondence between methods
supported
by different components. These relationships are usually given
implicitly,
either in the code or in textual comments. Thesis will also describe a
notion of "Interaction Compatibility", giving a more reliable match
than
just type compatibility alone. Thesis will also describe a method to
semi-automatically generate Glue in case two components are not
Interaction Compatible. This will facilitate seamless component
composition.
The four levels of contracts viz. syntactic, semantic, synchronization
and
quantitative are inadequate because often there are rules constraining
the
order in which messages may be sent between two interacting components.
We
assume that these messages represent the invocation of methods given in
component interface. In other words, real word components often impose
a
restriction on the order in which methods supported by them can be
invoked. For example, consider a component which handles a file
system. For such a component, a file_open method call must precede a
file_read method call. It is difficult to formally document such
constraints relating the two components by using four levels of
contracts
mentioned above.
I was wondering if there is any literacture / research work available
for this purpose which I can use as a reference. Also any suggestions /
help will be greatly appreciated.
Thanks and regards
--- Omkar Tilak

[o***@gmail.com]

Dr. Eugster,

Thanks for your quick reply. I saw your email id in your profile
and then I did a search on Purdue website to learn that infact you are
a professor in CS dept at Purdue. I'm studying in IUPUI and I'm working
with Dr. Raje (***@cs.iupui.edu). We have a project called as
Uniframe at IUPUI which deals with seamless integration of distributed
systems. A lot of work has been done on Uniframe project. Please check
http://www.cs.iupui.edu/uniFrame/.

I do understand that example given in my post is very trivial. But
my view is that even complex dependencies can be explained in
Interaction contract and checked for compatibilty during system
integration. Also maybe the information in Interaction contract can be
leveraged further to semi-automatically generate glue needed to couple
two Interaction-incompatible components.

I've already done some reading on TLA and maybe we can incorporate
some of the TLA operators in contract. So my hope is that this kind of
extension will increase expressive power of contracts while not
exposing too much information to outside world. I'm also hoping that I
can continue my Ph.D. research on similar lines. Any help from you will
be greatly appreciated.

Thanks and regards

--- OMKAR TILAK