Modeling Interaction (1): Frankel's thesis

So I wrote about "In" "Out" and "Very In" but it is just a way of having a prospect of UML and in particulara I have absolutely no objection to Action Semantics: in fact this is not about the potential value of this artifact, which can only be obtained through careful analysis of its primitives. However as far as I read from Frankel and heard from others, we may not know so much of the actual use of this tool. And this happens to be those things which describe very details of software's behaviour.

I am obviously interested in the diagrams for interaction --- including sequence diagrams, collaboration diagrams and activity diagrams --- which may change in UML 2.0 from the present shape but which I anyway am looking at as they are being used now. My interest is how they may be used as a basis for capturing (models for) distributed (application-level) interactions.

I start from a quote from Frankel's book (page 92):

In some cases and from certain viewpoints, interactions are an implementation detail best hidden from sight. In our accounts receivable example, a client of an ARProcessor that invoke the EndOFMonthUpdate operation should not be interested in the fact that the operation is performed by sequentially involving operations on some helper objects. From the viewpoint of the ARProcessor, however, the specification of such interactions is relevant.

I quoted a bit long since this part is precisely what I wish to elucidate in our investigation: if a subsystem (say A) calls a method of another subsystem (say B), then A does not care what other objects B will invoke etc. since what matters is what A's call to B achieves as a whole: you would say this is a natural observation but it is going to give us essential suggestions about modelling distributed interaction.

Frankel continues (directly following the previous paragraph) with a nice remark which is going to help us quite a bit:

On the other hand, an interaction model can describe a protocol whereby a request from a customer to a vendor for a price quotation is answered by a quotation that, in turn, is answered by an acceptance, a counteroffer, or a rejection. This kind of interaction is relevant to both parties.

Note that it is this second kind of interaction which we are interested in in our modelling/programming language. But what is a key difference between the first and second kinds of interaction models --- or in fact the target behaviours being modelled? In the first one, each "interaction" is part of a method, or a procedure/function whose dynamics is characterised by the standard stack-discipline; whereas in the second case it is not part of procedures/methods call return sequence but it is in fact an operation in symmetric communications which in general do not follow the stack-discipline. Summarising we may put these two paragraphs into a thesis:

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.

Note that this thesis is shy about the cases when interaction is part of symmetric communication though it does implicitly say that that the same thing cannot be said for a more general class of interactions. But if so why? What makes an interaction between software part of implementation in one case and part of modelling in the other?

There are at least two things we may observe on this difference between these two. In today's post (since I started late) I will only mention one, leaving another to the next post. What we may immediately perceive by looking at method calls (or RMIs) is its asymmetry:

1. invoke,
   
2. receives an answer
   

Here the callee may as well have called others: but it can be hidden from the viewpoint of the caller since there is usually a sequential thread of control which starts from the first invocation (1 above) through the intermediate chain of invocations and returns to the reception of the answer (2 above). The effect of all the nested interactions --- made explicit in e.g. sequence diagrams --- are accumulated into that of the outermost call: so we can only be concerned with this explicit call if we are modelling this interaction.

That is we rather wish not to worry about how this is done: it can be realised differently by different but equivalent implementations. What matters is what this call does. This is why Frankel's thesis is valid: all nesting interactions can be accumulated into an outermost interaction in function-like interactions.

Now we are aware how this is different in more symmetric kinds of interactions: clearly this "nesting" idea, "accumulation" idea, these ideas do not hold in general kinds of interactions. But then what kinds of abstraction can we have in their modelling?

Let's discuss on this topic more concretely in the next post, with examples.