Monday 23 July 2007

Modelling Interaction (2): Expanding Frankel

We keep Frankel but we also expand him. We first recall what we extracted as his principle:
Frankel's thesis: If an interaction is part of a method call (or similar) then it is a good idea to forget how it is implemented: what we wish to know is what it does, at least from the modelling perspective, not how it is implemented.
Let us re-quote from Frankel (already quoted in my previous post, which is here):
In some cases and from certain viewpoints, interactions are an implementation detail best hidden from sight.
Very careful isn't he? His example:
In our accounts receivable exampole, a client of an ARProcessor that invoke the EndOFMonthUpdate operation should not be interested in the fact that the operation is performed by sequentially invoking operations on some helper objects.
Fully agreed. So we conclude:
From the viewpoint of the ARProcessor, however, the specification of such interactions is relevant.
So different views give different ideas about implementation. In fact if we read Frankel's intention carefully we realise that his view in effect implies that even for ARProcessor, this detail (calling a helper method etc.) is uninteresting as far as our interest is in its specification rather than its implementation. So as far as we are interested in specification we do not need interaction details as described in sequence and activity diagrams at all, at least for procedural computation (there is subtlety about input and output: in fact this assumes there are interacting processes: on this topic we cannot touch in this post).

The combination of a stack discipline and the control given by a sequential thread (and at most collection of threads sharing variables) is what makes this simplification possible: and even in interaction such potential for abstraction takes place .....
Buyer is having a series of interactions with Seller: Seller in fact is always interacting with a wholesale agent for price and all details: but Buyer doesn ot care, and Seller may later purchase this wholesale agent so that these interactions later become unnecessary or radically changed.
We already treated a similar example in the "Paris-Hotel-Search" example (here): there is a protcol (interactions), and I am being engaged in it, and I use a "helper interactions" to make that work: but I may change this helper part without changing the other part, they are fairly independent. Then they are separate interactions (protocols) ....

But some interaction is hard to decouple: and surely (as Frankel noted) if Buyer asks for a quote, Seller answers with a quote, Buyer says yes or no, and if yes Seller asks for the address and credit card details, and after verifying gives the delivery date ---- such interactions gives a unit of interactions which cannot be divided. This is what Frankel called "symmetric interaction".

But (as we remember, from Class Models and Java and C# and C and ML and all that) for representing procedural behaviour which is roughly equivalent to sequential behaviour (or threads of sequential behaviours without explicit intereaction among them) the abstraction of a simplest asymmetric kind of interaction
  1. call
  2. return
gives us a basis for both modelling and programming. This is called signature. The signature is great, since just by adding precondition and postcondition and a bit more, you get a rather nice way to specify what you expect each method (and the class as a whole) behaves. You Signature, how great you are!

Because of accmulation of both results and effects in a sequential thread of control, we can always divide what we are doing into calls to procedures (methods), which are further subdivided, and a higher-level call does not have to worry about lower-level call: Well this is something everybody knows as a basic divide-and-conquer principle which is widely useful except for a specific situation such as upcalls.

In symmetric interaction, this nested division no longer works. And anyway the shape of interaction is not in the form of
(1) call
(2) return
It is more complicated. And here is one of the most basic things when we think about interactions such as Buyer-Seller protocol, Poor Buyers' Protocol (here) is this:
When you design programs which implement any of such interactions, you always start from the scenario of an interaction between the participating agents --- how they interact.
Is there anything interesting in what I wrote? If you find this uninteresting and a matter-of-fact business, then I cannot agree with you more: I am saying there is no other way than thinking about such reciprocal interaction scenarios that you can ever design such programs. This is nothing in fact! When you program interaction you are already thinking there are this and this and this participants, if not how interaction can take place? And this is just as the signature of interaction in a method call is always with you when you are programming a program. You start from a UML class model for example...or even just you start to program:
int foobar (string s, int i) {
.........
}
You are making the structure of interaction clear: just that this structure is very simple and functional so you do not think it is interaction. That is, in procedural programming you can be content with just this kind of interaction, its shape, it is called signature, and it has worked and will continue to work, not only for human being but also immature martians to whom we should teach how to program in (say) Java.

Or even residents in Andromeda Galaxi. I bet they are doing roughly the same, at least at this level of programming (not involving AI etc.)

Anyway the main point is if you program sequential programs or threads of programs which do not interact so much then it's very natural to build up your behaviour starting from this simplest kind of interactions and accumulating them.

However such sequential software interact with each other: you need interactions since both should decide what to do based on knowledge it gets from this person and another person and then it should be fed back and get acked by people there and then the same information should come back and get acked by people here which now allows you to say "hello" to somebody really important and then another level of transaction starts ---- this is just a way of life. Just think how you buy a book in Amazon for the first time --- you wish to be sure at each step, that is a "due process". This is also economical: you first get authenticated, then you declare you wish to interact with some company as a seller of T-shirts: that put you two into some mode where you do not have to confirm at each moment you are whom and what kind of things you wish to sell and therefore you should talk with which division in the department and therefore which kinds of protocols you should use ---- all that become unnecessary by having initial interactions which decide a specific mode in which subsequent interactions proceed.

And society also demands it. You do not wish your users to make mistakes all the time (by e.g. forcing to input all data at the outset): you do not wish to destroy centuries' old practice of lending money of banks (at least some wisdom in them); interaction is interesting because it is a social matter and, in turn, the social aspect of interaction is amplified when this is performed electronically: yo can interact with thousands of traders and refer to thousands of directories in a most efficient way for trading when you do your business.

So no way: you need a series of interactions and they will involve several parties. It is quite true that this is more complicated than:
(1) call
(2) return
I do wish all interactions could be usefully reduced to this form! This is possible when it is a chain of simple request-reply services: and there are such cases. But it easily becomes more complicated, even this Buyer-Seller protocol, and we wish to capture its interaction as a whole.

So, to make a long story short, my take is: if those interactions cannot be reduced to call-return then that is our dish: we should cook and eat it. And perhaps we can make a very good dish out of this and enjoy not only cooking but also eating...

So here is a tentative expansion of Frankel (already implicit in his discussions):
Frankel's thesis (expanded version): If a chain of call-return interactions are involved then you can forget all inner interactions from the specification viewpoint and can work on the outermost level, which often works inside a self-contained procedural software (i.e. without no explicit interactions among programs). If more complex inter-process interactions are involved then think otherwise.
So we need to think otherwise. And what is our quest? What do we want? We want something which gives a basis for modelling interactional software, which consists of communicating distributed programs: a firm basis which can be the inner core of a modelling language such as UML. Something like --- signature. Something usable as a basis of both modelling and programming (since if not how can we use that idea as a basis of MDA?). Something so stable that it looks as thought it can be used in Andromeda. Something which satisfies the conditions we stipulated in yesterday's post.

So we ask: is there signature for interaction?

Not the same signature of course --- but something essentially equivalent and as effective in the new enriched setting of interactional software.

That's something we want. And this challenge itself has philosophical malice in it.

But this blog is a place for practical discussions. And I believe we have a practical answer, at least a starting point. Starting from its simplest form, I will explain how this signature for interaction is motivated, how they can be written down and in what ways they may be used, through a series of posts.