Tuesday 31 July 2007

Before Next Day

Some note is due on the difference between signature, class model and behavioural description , before going into the next day. These three form (roughly classified) layers of descriptions of software, sequential or interactional. We take the existing (OO) practice as an example but the idea is the same layering also applies to or needed for interactional software.

(1) Signature: this is for example
int foobar(string, int)
which does not have a variable: it only has the name of the method (operation) and the types for argument and the result. For a class it includes all of its public methods and all of its field variables as well as its superclasses: the whole pieces of the information are called class signature.

(2) Class model: here we have a class signature augmented with, for each method
int foobar(string s, int i)
we add a variable. We can also add various constraints in the relationship between classes and their fields such as aggregation, n-to-m relationships, etc. A good thing of having variables is that we can now have DBC going all right: for example we can write using an informal syntax (for a formal syntax see Chapter 4 in Frankel's book):
int foobar(string s, int i) {
assert pre: s!=nul and Even(i);
assert post: Odd(result);
}
where "result" is a special variable for indicating the return value. The two assertions as a whole say that:
When you call foobar, you should specify as its arguments (1) a non-null string and (2) an even integer and then foobar will return an odd integer if it ever terminates.
Note we are using argument variables (i and s) to specify the precondition: a beauty of clas models is that we only need to have the signature and these variables, combined with field variables as needed, to specify the overall behaviour of a method. They are very good legs (of course if you specify the body of the method you can further annotate the statements with assertions). So class models offer very good legs for further modelling artifacts and tools, MDA-oriented and otherwise. The importance of the relationship between (1) and (2) is that these legs --- class models --- have class signature at its core: robustness of the former comes from that of the latter and the usefulness of the latter becomes substantiated by its use in the former.

(3) Behavioural Description: On the basis of class models we reach behavioural description. Here we can use varied techniques but a most familiar one is to prescribe how your system behaves by programming language you like best. One basic point: it is impossible to synthesise (3) from (2) in general and most practical cases: if we can automatically come up with non-trivial programs from specifications then we can solve essentially any number theoretic problems. No need to despair since DBC is useful precisely because of that: this allows declarative description which is independent from how the behaviour is implemented.

* * *

For the design of scribble, it is good to know the distinction between (2) and (3): and for (2) understanding how it is induced from (1). In (2) we have no control structures, no assignment, no function calls: however it offers foundations of software upon which these elements are built one by one.

In the initial design of scribble we focus on (2) together with the basic parts of (3) which should be useful even for the concern of abstract modelling. The distinction is fundamental for both practical usage of scribble and conformance to the UML architecture: but it is also fundamental for us to be able to smoothly go between these two, just as we can go between (2) and (3) smoothly in object-oriented software development.

Monday 30 July 2007

First Days

1 In the beginning there were interactions. Then interactions formed conversations. There were more conversations from more interactions, filling the earth. Conversations were separated from non-conversations.1.1 This was the first day, when we first had conversations.

2 A conversation needs conversants. So it was said, ‘Let there be two or more conversants in each conversation.’ 2.1 Then conversants are separated from conversations, and so are called participants. This is how participants came about. And there was evening and there was morning, the second day.

3 Interactions in a conversation need be addressed at ports, to avoid confusion, since confusion was evil.3.1 It was said, ‘Let there be one or more fresh3.2 ports for each conversation.’ Ports are separated from conversations, and so are called channels. This is how channels came about. And there was evening and there was morning, the third day.

4 It was said,
‘Let an interaction in a conversation be with an operator and values since it gives us both rigour and freedom.4.1 A decree therefore said:
An interaction consists of a channel, a participant who sends it, a participant who receives it, and an operator, and messages.
This was the fourth day: it brought a decree for an interaction.

5 And it was said, ‘Let a conversation be thoroughly distilled and the result be separated from a conversation, called the signature of a conversation, and in it include the participants it uses, the channels it uses, and the paths a conversation can take, where a path can branch or loop or escape.’ Signatures of conversations were separated from conversations, and so were called protocols.5.1 Each conversation has a protocol, and obeys a protocol. This is how protocols first came about. Two conversations which have the same protocol are similar. Two conversations whose protocols differ are not similar.5.2 This is the fifth day: we now had protocols.

Comments: We covered a lot in this first post. Two more posts are enough. "Separated" means an idea is articulated as an independent concept, like from water we find liquid and coldness etc.

1.1 Separation of a conversation as an independent structure is the starting point of this whole design endeavour. Historically this was first done (perhaps) in cryptographic protocols and later in UML sequence diagrams as well as in message sequence charts, and with more type-theoretic inclination in session types.

2.1 It is assumed that even if a participant has two threads they are not to converse: you can use sub-conversation (and sub-participants) so this does not lose generality.

3.1 If Alice sends to Bob two messages in parallel and do not wish to incur confusion then Alice can send it to two channels at Bob and Bob receive them as distinct messages. Channels can be omitted from scribbling in some cases though they are always implicit in descriptions.

3.2 Here "fresh" means (like variables declared inside a block) each channel is made fresh for each run of a conversation.

4.1 If we wish to be without an operator use a default operator "send". The use of operators is to use them as labels when we abstract a conversation as a finite state automata. So it is good to use them. Scribblers may as well start very informally however: our language formally defines how we can be informally in different ways.

5.1 A protocol is extracted from a real conversation, distilling its fundamental structure as a finite state automata. A protocol should not contain any concrete expressions nor their evaluation since if so it is not "thoroughly distilled": it should only contain static structure and should still be able to check whether a real conversation follows a protocol or not just by checking its program text (this is the MDA part of the signature). A real "class model" (which we shall call "conversation model") will include a little more than this, but it is good first we fix the notion of signature, since unlike signature in OOPLs we do not have this idea explicitly beforehand.

5.2 Thus a protocol can be used for classifying whether two programs realising conversations are similar --- in other words we can check whether a program conforms to a conversation structure given by a protocol. A protocol is a way to classify conversations, just as a class is a way to classify objects.

[to be continued to the next post, moving to internal structure of conversation]

Saturday 28 July 2007

Intermezzo --- and Prologue

Dear sirs and madams,

While I was wishing to start to tell the history of conversation types from this post, it occurred to me that recounting dry historical facts must surely be a very boring business not only for the readers but also for myself. For this reason I have decided that I may drop this idea (at lea.st for some time) and start relating this story, the same story, in a somewhat different way.

The more I think the more certain I am this is the only way this story can be told. The narrative I choose is an axiomatic one. We all know there was that emptiness before all things began, before somebody said there be light. You may call it big bang if you like. Then that emptiness was fiercely burning. That sort of emptiness which is in fact not emptiness we can feel when you hear (pardon me for this banality) when we hear Horowitz. Even he played Star-Spangled Banner. It was there. But there are also other moments, more (or as?) transparent moments, for example when he plays Scarlatti...

We are not going to tell that story (genesis or music). It is far, far more modest story, a much quieter story, though nevertheless it will also talk about the beginning: and neither will it talk about the ending since it is a story which is continuing. And you know what it is about. And so --- because all things scientific will proceed through dialogue, it is about a dialogue which comes out of a dialogue and the truthfulness of the matter itself may only reside in these conversations, carried out over chats in workshops in low voice and mail exchanges --- perhaps it may not become as axiomatic as I intend it to be. But may it take any form it can under this humble narrator. We shall start tomorrow.

Yours truly,

kohei

Friday 27 July 2007

a question for today

I have time only for a question which came out from mail exchanges between Gary and me, on one of the basic points we are discussing, in fact an old problem since 1970s:
How can we represent that elegant, that nice "call-return (or *request-reply*) structure in asynchronously communicating processes?
Here our question is not when a conversation as a whole has the request-reply structure: rather when this structure occurs inside a conversation, as a micro protocol. You ask somebody a question: and perhaps he will ask somebody else (or even you) a different question: and after a few (or a few thousands) interactions he will reply to you. But these two interactions are paired: how do we represent it?

In the next post I will continue what I started in the previous post. And some posts later we shall be able to come back to this question. Today I just post the question.

Wednesday 25 July 2007

Signature for Interaction, Part 1: binary case

Well I do not find time today --- my plan was there is going to be brief and gentle illustration of signature (or types) for interaction, with many examples, and this will happen, but not now. And after that introduction we shall come back to "Modelling Interaction" in its third installment, at which point we shall be able to articulate the principle augmenting Frankel's thesis with a concrete notation with which we may be able to write what may correspond to "class models" in the present setting (NB: not yet with graphical syntax --- that is for later).

Our narrative can be interrupted by other interesting things which are taking place --- so the narraive may not be a completely continuous business but the basic structure is like that.

By the way a brief report: based on Gary's syntax we are now converging into a rather neat syntax for scribbling ---- I think it is neat. It's curly but not too curly --- but it is at readers' discretion to judge how cosy you find it.

* * *

I cannot spend much time but why not just to give a flavour of what we are going to discuss from tomorrow? A prelude...

Here is a bit of signature for a method:
int foobar(string s, int i)
As we already argued this is a notation for a special (and very tractable) instance of interaction.
Then why not we can write this as (the following is not that syntax Gary and I have arrived at: it is one of the syntaxes we once used as the signature for two-party conversation):
protocol Foobar {
foobar ?(string, int);
!(int)
}
This is a way to abstract how somebody receives (?) two arguments with an operator name "foobar" and returns an integer. But why we are using such marks as "?" and "!" ? Easy, since we are in the symmetric world:
...... This kind of interaction is relevant to both parties. (Frankel)
But request-reply is also relevant to both parties. If we consider the "interaction" signature above from the caller's viewpoint, what we get is:
protocol FoobarUser {
foobar !(string, int);
?(int)
}
where we have exchanged ? and !. We have not done much, but this time this "signature" represents a user/caller's side of the story: the user sends with the method name "foobar" with a string and an integer, and then receives an integer. So this notation is symmetric: it assumes that interaction is "relevant to both parties".

Haven't you never thought that it is strange that we can write a method signature from the viewpoint of a method but not from the viewpoint of its user? Well in functions we do not have to distinguish them (since functions accumulate ...). But now we can --- and need to --- write both sides of the story. Since the world is now symmetric in general.

Of course this notation becomes interesting when we treat more complex interactions, on which we shall discuss next.

Before closing for today I record when this idea of signature happened: it was 1993. And we thought we found types for describing interaction rather neatly, one of the possible candidates for "signature for interaction". Well we never knew at that time how far we had to come from there. This was the beginning, and perhaps even a nice beginning too, but still "signature for interaction" simply it is not: it does not serve our purpose: it serves some class of interactions well, but not their whole.

So the next post will discuss good stories and bad stories about this notation: how this notation nicely sevres as a way to describe, abstractly, many kinds of interactions and validate our programs against such descriptions: and where, to our dismay, it fails disastrously; and why it does so. That observation will lead us to a more general idea of types for interaction whose finding needed many dialogues with our respectable industry and academic colleagues (and which by the way has already been implicit in the notation above, as it turned out --- but without our ever knowing, as is often the case).

And at that point we shall become ready to do real scribbling...

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.

Why We All Love Signature

Later today I will post the sequel to what I wrote quite a few posts ago titled "Modelling Interaction (1)" (here) which will have an exciting title "Modelling Interaction (2)". I think I have given enough bits and pieces --- so perhaps it is time to carry on.

Here I only leave some words on "signature" which your UML class models always contain
(in object-oriented programming signature is usually called method signature or class signature though its origin lies in algebra and the idea applies to any functional and imperative programming languages). The key static abstraction in this procedural (or functional) paradigm is the combination of
  1. data types (for the structures and names of objects, data, ..)
  2. procedures or methods (for the structures and names of dynamic behaviour)
Even if the other, what may be called interactional, paradigm may demand changing this combination, or rather all the more for that, it is good to see why this combination is rather nicely usable as a basis of both modelling and programming languages.

That is for example as a basis of UML and Java/C#/C++/C++/ML/Haskell...

Apart from 1 (in fact there are a lot to day here too --- for example remember that any class model contains its method(s) --- so this static part which specifies data already contains a basic abstraction of dynamics, in fact passing an object is more similar to passing an agent than you would imagine, at least logically) yes we do have a lot to say about 1 but our focus on this brief post is 1. Why this is having a universal appeal as a basis of so many things?

In addition to the fact that this abstraction is enough when considered behaviours are mainly sequential, as we discussed in the preceding points, there are several points which give this abstraction the qualifications to serve as a key static structure on whose basis the description of behaviour is built:
  • It represents the key handles ("constructors" in technical terms) for the dynamics of computation

  • It serves as a bare minimum and sufficient basis of specifications (annotate it with assertions and you get DBC).

  • It is easy to write and checking programs' conformance to signature-based models is easy (since after all all classes mention their signature!).
Let me say this notion of signature, or rather functional signature (including class/method signature), will live for many many centuries. As far as one has a notion of functions. As far as we know that composing functions is a rather nice way to build procedural behaviour.

So what we are searching for is something close to functional signature in terms of usability but placed in the context of interaction: something which may serve similar purposes but does so in this much enriched world of interaction...

Saturday 21 July 2007

On waiting

I ate too much of tandori chicken today and could not think. Well perhaps I can write a bit about waiting for synchronisation. With interaction you depend on others (like when you have a lunch in a restaurant with your fiance) so sometimes you need to wait. When is waiting tolerable? Here is some maxim...

You never wait when you need not to
But you may wait for a short while if you don't mind
And you may as well wait when you judge it's worth

We shall come back to it. Here is one for good Tandori chicken...

Friday 20 July 2007

Poor Buyers' Protocol: another kind of interleaving

I did not wish to present this protocol so early, if at ever. No. What was our previous example? Well it was a call back and its generalisation. My idea is to refine it further to reach a fully fledged financial protocol from fpML.

As an intermediate one, I could have for example used the Buyer-Seller protocol. That is already classical. But poor buyers' protocol --- this one will never have a proper status in the History of Conversation Protocol.

No it will not have any kind of status. But it's a simple example one can fully comprehend and it has its own subtleties --- and it does tell us something about interleaving. It is so to speak the other extreme of interleaving, in contrast to "hotel search" example. So I decide, Caveat Emptor, here it goes:

Two buyers, Buyer1 and Buyer2, wish to buy an expensive book from Seller by
combining their funds. After agreeing that they enter a protocol and establishing a link, Buyer1 sends the title of the book to Seller, Seller sends to both Buyer1 and Buyer2 its quote, Buyer1 tells Buyer2 how much s/he can pay, and Buyer2 either accepts the quote or receives the quote by notifying Seller.


I put the sequence diagram presentation (due to Marco) on the right-hand side. Simple-minded as it looks, this protocol has one basic form of interleaving of conversations. To see this let's see how many bilateral conversations this protocol consists of:
  1. Between Buyer1 and Seller
  2. Between Buyer1 and Buyer2
  3. Between Buyer2 and Seller
Well, when Seller sends out its quote to Buyer1/2, perhaps this may be counted as another unit. Anyway these different conversations are interleaving in this protocol. A basic point I wish to communicate in this example is that: each of 1,2,3 above does not make sense by itself. So this is not interleaving of several conversations. The whole interaction sequence does not make sense in its bilateral decompositions: they as a whole create a single conversation.

So in such a case we do not call this interleaving since after all this as a whole makes up one protocol, one conversation. So we are forced to capture the whole of this structure as one abstract unit.

Function signature can add callback (Java programmers are already adding exception to it). And certainly in some cases interleaved conversations can be ignored --- you still just have a function signature as your basis, you wish to forget about it.

But in interaction this is different. Sometimes you need to capture a chunk of multistep (and even multparty) collaboration scenario in one go ---- that is a unit of abstraction, that is a unit of modelling. And this unit is reached as a gradual elaboration of that familiar notion of static structure in modelling and programming, the class/method signature.

So today's story ends here. I know I have not fully conveyed what this paradigm shift is telling us. I mean, I have here something I wish to tell, but perhaps it has not made a truly clear picture I wish to make.

But that is not to be avoided. Through conversations we shall reach a good understanding. Today just a problem presentation: what is this? how can we use this for our abstraction?


Thursday 19 July 2007

typing up proofs

I am in the final stage of typing up proofs. Not so difficult proofs but interesting proofs since it is about types for interactions. This is for business protocols. This is for financial protocols. This is for high-performance computing. This is for many other things. And this is above all and most of all for scribble and languages with the same ideal.

Typing up got a little late, but I am finishing (I am sorry I have been so occupied with thinking and typing up proofs: anyway it is finishing). About this theory which I am finishing you will know about it here, in this blog, what it is about will be discussed.

Simple fast and furiously under control. Write freely, get it right for sure. Is that what you want? Well that is also my ideal. I wish to discuss a lot but now I should continue typing. See you in the next post.

Wednesday 18 July 2007

Intervention ---- or interleaving

That is the topic I will discuss tomorrow (or in the next post). When you ask a travel service on the web to find a hotel in Paris which can host two dogs and three cats and five babies together with one wife, and perhaps a neat (not too tall!) pet giraffe too, which should be near Louvre (which is such a terrible and great place to go which has everything) and which has a special "baby and dogs washing service" which is in some way nice then well what you are doing is you are asking somebody

If that service again asks "special hotel directory" then it is all right for the travel service it wants a service from somebody. Then it receives an answer and returns to you.

In functions this is just calling somebody and that guy again calling somebody.

In interaction this is interleaving. A hotel is talking with two parties at the same time, one a special hotel directory and another a client which is you. At least at some point it is talking with two people.

There are two kinds of interleaving. One is an inevitable, unescapble one, it is destiny, do not forget about it, it is strongly connected. in this case the interleaving is part of the whole conversation. It should be specified. In particular I may as well expect it. And changing it means changing conversation structure.

In another, it is more loosely coupled: for example perhaps the travel service can ask not a special hotel directory but another travel company. And perhaps I do not care. What I want is a room in Paris which is near Louvre to which I can bring five babies and a pet (well I do not repeat) so I do not care what people that travel service talks to as far as it serves the purpose.

Today that's all: I just wish to record there are two kinds of interleavings. We used not to care so much in sequential programs. Because it is functions . A function hides another function. But in interaction we have more variants. In fact a huge variety. Can we digest it...

Tuesday 17 July 2007

meaning of proving something

Do not think it is just for "correctness". It is a condensed way to explore the terrain, in this case the universe of describing interactions.

It's difficult to communicate what this universe looks to me --- even snails or its very specific stage of development has infinite wonders in it --- but one thing which I can say is this is complex and has that recurring harmony which is so hard to characterise as that nature like complexity of this universe: it is too real to say it is harmonious and it is very harmonious, I cannot change it I can just discover it. But still what we are doing is the taming of complexity.

I promise in the next post I will be an experimentalist but today I am a theorist and I know the order is there. In fact that is the only thing I have, that evasive instinct (and a bit of a gut of course).

kohei

Sunday 15 July 2007

almst done

It is true around thsi time is a ritual but Claudia in Paris told me:
This is the time we can obtain a lot of knowledge about new things
So let's carry on....

And I am sorry Olivier I cannot go into it but I am always carrying it with me!

See you later

Saturday 14 July 2007

Everything is going well

I mean about this poor-two-buyer's protocol. But that keeps me busy.

I think good designers of application-level protocols should not worry about details --- but I think what people are doing with current CDL is roughly isomorphic --- rather crudely roughly isomorphic --- to something close to part of an optimal picture.

In other words I have a lot of reservations but I may be perhaps one of the people who know very well about its virtue: and perhaps we can be a little greedy about virtue.

Nothing is without side effects. This does not mean we should not have a moral judgement in our daily life. All our judgements are sort of stupid. But it does not prevent us from seeing something is very stupid and perhaps also from our trying to do our best.

Even if that understanding may not be understood by many --- and even the most wise can be stupid in some other aspects.

We are human and limited. Such a limited being... But let us do our best: and let's believe in that we can try to reach something very good. And let's also appreciate what we have, ourselves and our history, since (as Hegel says) they are there with reasons and (as some scientist would say) that is perhaps the most pragmatic way (and that scientist told me we should be practical about pragmatism: indeed sometimes we need idealism not from cynicism but because it is really something we should cling to; for example sometimes we should argue for equality of humans and we know no two human are equal: but we do need an ideal sometimes: not of course to make us human more stupid, even crazier --- and we know that an ideal was, and is being, used numerous times that way --- well the idea is to use ideals to make ourselves a little more wiser at each step as we proceed, we should not believe too much but some basic faith in our ability to proceed is not bad to have).

If the readers of this blog have any doubt, let's enumerate two things which are good: natural numbers and the pi-calculus (and I know Turing got very excited when he found his machine as recorded in his letter to his mother).

So one can find a good thing. One can know and identify that something is very good. We can surely do good things. So let's try to do good things and make the best of our life ... and in the present context let's design a very good language for scribbling conversational interactions.

Friday 13 July 2007

Time

Well I do not have time today. So perhaps I can write a little about time. This would be just a memo for me: if unreadable my apologies.

Of course we need to put time into our language --- at some point. How can we set time?

(1) independent timer (this guy throws something when time has come).
(2) we put put explicitly how long it can wait without relying on timer.
(3) we can put this as an assertion

Pros and Cons:

(1) timer:
pros:
This is very flexible and expressive
A lot of people know how to use it
cons:
Very operaitonal
Does not have full expressive power without "atomicity" block in the language

(2) elaboration (annotation) on input etc.
pros:
This is the standard case
Moderately declarative and can do something timer alone cannot do

cons:
Still operational
Is not as flexible as timer --- we may need many kinds of elaborations

(3) assertions or design by contract
profs:
Looks promising

cons:
Perhaps we do not know how to do this generally and cleanly.

* * *

So here is a question: can we use (1) and perhaps atomicity to think about (2) and (3)? That is can we consider what kinds of assertions (design by contract) are there by going back to their operational content?

In either way we need to start from a concrete example (or two). And I do have a concrete example --- on that I will discuss in later posts. Today I do not have much time...to talk about this rather basic subject fully.

Wednesday 11 July 2007

Timing

Timing is important --- "There is a time for everything" as Bible says --- and today my timing is not too good. So not much today but let me tell you I am enjoying this --- this which is not (only) this blog but the process of designing languages with you all.

Well at least I can say one thing:
If you are not sure how your software should behave,
even if vaguely,
then there is no point to try to validate your description
You can check only what you want to check
Since you should specify first
You need to check your description
With your another smaller description
We need pairs as in many activity of human being
to do checking
Here two descriptions
Two scribbles
Almost always in different languages
One (usually big) is checked against the other (usually small)
But they are not against each other
Or so we wish them to be
We wish them to be harmonious
But either warring or harmonious
We need a pair
A pair of scribbles
Which we are going to design
Yes friends we also need that language, the language against which the main "language" is checked against. To say the truth I know we need thousands of languages --- often called "specification languages" but how boring this term is --- but let's not despair since we can always start from one..

As always, from a nice and simple one...

Today I only said one thing that is we need thousands of DBC languages but we can start from one. That language will be small amd simple and will be connected organically to the main languages. This I would say is another serious fun.

Questions and --- Questions

The title is a best summary of my chat with Gary Brown, with whom I am designing scribble: we find there are many questions, to begin with. But without good questions how can we do something as bold as designing a new language? Here is a brief summary. I am a bit in a hurry (still working on poor buyers' protocols etc) so I will hurry through today and will augment it later.

All these topics were first suggested from Gary and later we discussed and agreed that they are interesting questions. Isn't it nice?

1: units of description: static or dynamic?


This is about description of behaviour, a unit for describing behaviour of communicating systems. How much can we learn from the existing wisdom? One of the basic paradigms for description units are clsses. Now classes have both static and dynamic sides: if we follow Should we follow behavioural aspects of classes? Perhaps that may not be effective? In modelling we should not be too operational... But where is the bounday?

2: need data types: but what kinds?

This is data types for messages. There are several aspects.

(1) Should we have an intrinsic data type for the language? This can be:
  • Something good and widely used: for example UML data models (with some fix in aggregates: a note from Matthew)

  • Invent a simple. clean and neutral data type definition for the language.
(2) We need --- dearly need --- a language mechanism to incorporate data types from other languages: surely UML, XML schema in general, Java, C#, C++, ML, ....

(3) In all cases it is important that validation of data types is easy --- your description should be consistent, if it says it is carrying integer it should not be carrying a floating point (but such a check may be needed at runtime: consistency however can be checked at runtime). Of course we first of all want description can be easily done.

3. package-structure --- to organise different kinds of description units

OK we need packages. We are talking about millions of description units for a large corporation ----- so there is no question about the need of packages, which are hierarchically organised (usually through a hierarchy of sub-directories or sub-folders in your file system : we can think of graph structure but perhaps this may be too much).

An interesting thing in the context of scribble is we have not only one but multiple kinds of description units. Let's recall:
  • Units of global description of behaviour (choreographies: this will also have several kinds including abstract and concrete ones)
  • Units of endpoint description of behaviour (this describes how each endpoint will behave) And perhaps you want endpoint description written in other languages such as UML and Java...
  • Units of data type description (as noted above: this can include how we can import data types from other languages and facilities)
  • Units of description of structures/properties of participants (it looks this is not part of data types --- these guys use behavioural description...)
  • Miscellaneous descriptions such as bridges to other language/description environments: this also means you can have diverse code units inside your package structures
So there are a lot. To make discussions concrete suppose the standard situation where we use data type definitions (say class/interface definitions) together with behavioural descriptions for describing the behaviour of an interacting system. The latter uses the former: how can we organise them?
  • Always put a data type definition in the same directory as that of a behavioural definition.
  • Put them separately --- since perhaps we want a generic type used in many parts of the package hierarchy for behavioural description.
The former is individualism while the latter promotes sharing. In both cases however it looks it is better to have a single hierarchy for all of these unit types and allow a flexible way to designate these units.

One important point: let's start practically, centring on a specific practice --- such as corporate systems modelling with a slant towards EDA. Then something concrete will come out. If we can find something simple and general in a specific setting, at least its basic elements have universality.

Let's consider the possibility that there are several kinds of universality.

4. Why need two kinds of description methods for interaction?

We need endpoint description language: why?
  • This is the target of endpoint projection.
  • So it becomes a basis of mapping to other languages (such as Java)
  • And it may also be used as a prototype code in its own right to be elaborated.
But the most important reason we need this may be because sometimes we need to start from the endpoint behaviour, for example for existing services or by starting from a service used by many independently from its usage by other guys.

My personal view is that when we are defining a global language we may also be defining an endpoint language --- a basic note is we need a good EPP framework for relating them.

5. We need hooks: and mechanisms to use them.

To connect the descriptions to real-world entities we need hooks. Such hooks are associated with validation mechanisms: for example consider the data type import we discussed in 1.
When validating our behavioural description, it mentions UML class model, then it uses UML class model validation for the purpose of checking everything is all right.

This can happen also internally: we have a global description and an endpoint description and our validation engine checks all work fine.

Or this can be about assertions, or design by contract as it is being called. It will check at least assertion annotations are type-correct and syntax-correct --- and as much as possible it can check if the given description has (at least!) a potential to fulfill the requirement given as assertions.

Or suppose we can add other annotations --- security annotations. A consistency check and other validations can be done in this case too.

So we need hooks and a way to make the best of them. We do not have to aim to have a universal language for such description but we need something basic and even if they are bestr realised by scribble-external facility, we wish to capture a basic shape of how these things can work and at least provide a basic facility for basic features we decide upon. So again we do not try to offer something universal but let's remember the basic staple here, a hook and a validation mechanism go hand in hand.

* * *

OK I finish today here. I hope I at least covered all basic items --- if not all details of our conversation. I may augment some of the points in later posts.

Tuesday 10 July 2007

got late --- or early.

Today I was intending to record the joyful chat I had with Gary a few days ago in this blog.

However I was thinking about what may be called Coordinated-Buyer Protocol and somehow lost the chance (in fact time) to do so: where two buyers (perhaps two children) are too poor to buy their favourite book alone (well can be two adults who wish to buy one of the earliest copies of Erasmus bibles) so that they need to put their money together.

Another protocol I considered is a Simple XOR Protocol which has an XOR node receiving a key stream from a producer and a stream communication from another: and it does what you know very well (which your mobile is doing every day).

A detailed story on these protocols will be discussed later.

About the record of the chat, I am determined to do this, so this will be my next post, perhaps tonight (which may become today or tomorrow: it's too early to tell, isn't it?).

In anyway see you later...

Sunday 8 July 2007

First Examle

Started a little late. Anyway, when you move from sequential to concurrent/interactional computation the structure of a conversation becomes larger. The call-return pattern:
A->B: ask a question
B->A: return an answer
is a good pattern for sequential computation (well I will explain) but may not be so for a call back pattern:
A->B: passes a handle
B->A: calls that handle
A->B: says OK
which may be done as a single conversation. This simplest form of extending call-return pattern can be extended to an unbounded callback pattern which may be useful for e.g. updates for auction:
A->B: passes a handle
B->A: calls that handle
A->B: says OK
B->A: invokes that handle
.....
which may be done as many times as needed, all in a single conversation: here B is a server and each callback from B is an update of a bidding price.

Well a real auction may be abstracted in a slightly more complex pattern. In my next post --- perhaps a day or two later --- we shall present a little more complex example including those by Gary.

Friday 6 July 2007

not much time,

Just to say what is a protocol: a user-level (or application level) protocol, such as a financial protocol, is a predictable sequence of interactions among participants.

Since it is predictable it has some structure. This structure is articulated not at the level of e.g. packet switching (such as description of TCP as a system-level protocol) but at the level of high-level interactions.

A very simple protocol is a remote method invocation: in fact a local method call may already be regarded as a protocol. It has the following structure: there are two guys, say you and another person. You call the other guy, and you get a result (or an exception) from him/her.

So there is first one-way message from A to B: then there is another one-way message from B to A.

Well not only that: this second message is received by A with the understanding that this reception is understood to be the return associated with the first message.

That is A knows that this second message is in the same conversation as the first one was in.

Well this is one of the simplest forms of non-trivial conversation: you ask, and you get an answer.

The type structure associated with this special form of protocols is called signature. We recall: it is two-party interaction, one calls and the other returns. That's how this protocol is. Very predictable.

Well in fact it has a bit more: an object (or associated class) can have multiple methods: in that case you can invoke with different methods. That is also part of this protocol: you can call the other guy with one of the different options (with arguments), and the other guy reciprocates it with her/his own message, which consists of a single value.

Of course in real computation you use a lot of method calls: .but we are content with having a single method --- or a collection of methods for a class --- as a basic static structure for sequential computation.

Why so? We did say something about this the day before ---- and yes it is related with sequentiality in computation. But we need to further explore this point in the next post (I am sorry I am trodding with the pace of a tortoise, today is not the best day for a jump).


Thursday 5 July 2007

Headache

I cannot write today due to a headache. One point that just occurred to me:
An application based on disributed interaction will use multiple languages as its endpoints which can be written in different languages such as OOPLs as well as functional languages. So the modelling/programming language for interaction should be able to work with languages with different paradigms: perhaps it may best be language-neutral.
Well this last thing is not too difficult since at least at the most basic dynamics, sequential languages do not differ from each other.

So what is the point? Well I just wish to remember that we shall deal with many endpoint languages which may differ in their styles and paradigms. This language should be for all of them.

Wednesday 4 July 2007

Today just a few lines...

This afternoon Gary Brown and I had a good chat on scribble design and many interesting topics came out which will be reported soon in this blog. It's great we are working on this project.

Further discussions on Frankel's thesis will be posted tomorrow: I am sorry, I cannot find time today, though it's all in my mind and even now is about to come out of it. What I started yesterday may be called a geneology of procedural modelling, or why the "stack discipline" is so good for modelling a class of computation. But then I also hinted an implicit assumption which makes this beautiful idea work...

Understanding the greatness of this existing idea --- that a computation can be abstracted by a notion of operations, which underlies varied languages including C, Lisp, Java, Algol, Erlang, ML, ... --- is one of the effective ways to reach a solid MDA foundation for communication-centred programming.

Maybe you find this a timid way to approach the new realm, the modelling and programming
for distributed interaction --- well I wish to be careful here not to lose the sight of one of the best things we have now, however mundane they may look after a few decades of its usage. It is also a way of introducing new ideas using the old, mildly and with care.

So see you tomorrow in this blog...

Tuesday 3 July 2007

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.

Monday 2 July 2007

What are "Out", "In" and "Very In" in UML

It's a crude way of classification and is just a way to have some prospect. Or you can think that I am doing this just for a fun.

What is "Out" in UML are those features which are almost never used in (real) practice, for some reason. Not that they are not useful but somehow they are not being used. Such as action semantics...

What is "In" is those features which everybody uses or everybody may be assumed to be using. This includes use case diagrams, sequence diagrams, activity diagrams, and all features which are Very In.

So what are "Very In"? Of course this includes UML class models offering specialisation hierarchy, attributes and signature of each method (operation). I also wish to include DBC features which associate OCL-based assertions with signatures in class models. So what are "Very In" are those features universally used and/or respected as foundations of MDA and business modelling.

What I wish to say by this classification is simple, and can be summarised as follows:
  • Classified as "Very In" above concern the fundamental static structures of software, together with declarative assertions associated with them. In particular they are model elements which Frankel called Development Artifacts ---- formal artifacts which can be used for model transformation to develop programs from models, or at least check their correctness using a mechanical means.

  • "In" on the other hand concerns dynamic structures of software which are useful to get general ideas but which do not have a formal basis ---- so these are, in the dichotomy by Frankel for model elements, Design Artifacts and not development artifacts. they can surely give a sketch of the general ideas of software and useful documentation but may not be material directly useful for MDA proper.

  • "Out" again concerns dynamic structures --- and they are about detailed dynamic behaviour of software hence non-declarative, operational specifications on dynamics of programs. They are what would be very close to "implementations" from the viewpoint of software architects...
(As to the last item I am not against having dynamics in specifications --- this is a fascinating subject we may as well explore. Also a lot of UML features do not fall into these categories as clearly as can be.)

A plain fact about UML is, as far as what is being offered currently, the situation is that "Very In" is widely used or respected and moreover offer essential ingredients for MDA; "In" is again very popular and useful though they may not be part of MDA proper since their correspondence with realisd programs is hard to be made formal; And "Out" is the remaining bits in UML (which can of course later be classified otherwise).

So one question is in which of these categories we wish to introduce the modelling artifacts for distributed interaction, and what kinds would they be: we want some modelling elements useful for specifying financial protocols and more generally interactions among distributed participants. This is our question and we wish to answer this by asking the following question:
Why does Frankel say that interaction (i.e. how objects interact with each other, as given by activity diagram) is an implementation issue in UML?
Frankel does not explain too much in detail but given his other discussions in his book there must be a good reason for him to say this. In fact when we answer this question, we shall start to see the concrete shape of modelling artifacts we would be needing for our endeavour, tohether with their positioning in our trichotomy and in effect in the general modelling framework.

The rest for the next post (by the way I may update the "model hierarchy" post yesterday since I found it reads boring: while in fact this is a very exciting idea...).

PS: Gary, please do not despair by my long-winding introduction before we can go into real design (though for me the present discussions are also very real). I share your desire to go into the decisions on: what are the (top) units of descriptions; what are the type structure of the language; what are the fundamental control structures; and so on and so forth. And I admit that my discussions may not always look taking shortest possible paths (at least for readers!), and my English is getting worse and worse after starting this blog (I will correct at least glaring mistakes soon).

And yet, we certainly wish to be clear about what kind of language we are designing (e.g. for programming and/or modelling); and for that purpose, we also need be clear what does it mean to do programming, what does it mean to do modelling, in this new realm of software description we are working on. And to understand the landscape, it may be worth even going back to the modelling of non-distributed software through the representative design method such as UML, since in that way we may be able to obtain wisdom from our accumulated experience and well-understood foundations.

So I hope that you can bear a few more posts before we go into discussions on concrete design elements.