Before even starting to discuss the central elements of our scribble design, one key point needs be answered. When we scribble interactions, is it for programming interations or for specifying (or modelling) interactions? In fact what is the difference between "programming" and "specification/modelling"?
When you write a sequence diagram in UML, certainly you are not programming: it may as well be part of your programming activity, but what you creat --- the sequence diagram --- is different from programs.
Programs describe (or prescribe) behaviour, the behaviour which you wish to realise when programs are executed. So if it is a sorting program, then you specify the behaviour by which it receives a list and returns the same list except its elements are ordered. Or if it is a word processor then it realises the behaviour by which characters are displayed and edited and printed following your typing in the keyboard. The same with for example video games. So programs realise behaviour.
Well we can be more precise taking into consideration how in reality a big software is made up of. A behaviour is often made up from sub-behaviour which is not so interesting from human usage but is essential to realise the overall behaviour. For example the only interest in the sorting program is when we input a list of (say) integers then it outputs, after some calculation, the list of integers which are the result of sorting the original integers. But for realising this behaviour it should contain a sub-behaviour to extract an integer from a given list, compare two integers, reorder and create a new list, for instance. So these algorithmic (and other) sub-behaviour is also part of the essential "behaviour" we wish to realise.
The same thing can be said about communicating programs. Consider an application whose key elements are communications among endpoints (such as business protocols). At each endpoint of that application, one or more processes are running, and each such process may consist of many threads. While what we are most keenly interested in would be the top-level interactions among these endpoints, these threads may be communicating among each other to calculate the value to be communicated: for example each of these threads may be running in a different core and they may together be calculating FFT (fast fourier transform). In such calculation, a thread may be engaged in even 1 million communications per second: and the accumulation of these communication sub-behaviours realises "the" overall communication among the endpoints, that is the business protocol we are interested in.
Well this has been a detour: the main point is that the programming is for description of behaviour to be realised when that program is run. In your description computation is encapsulated which is jumping and kicking if it is unfolded. what a fun.
Specification, on the other hand, is a very different activity. First we should admit that specification is also about behaviours: but this time we describe behaviour by writing down their properties. We write properties --- such as: if this program is run under such and such conditions it will terminate and gives a good result. For example
{x=n} P {x=n!}
If P is a program, this specification says that if we start from the content of x to be n then
after P runs we get the factorial of n as the content of x. We can extract the property part of this specification:
{x=n}, {x=n!}
so this pair gives us a specification of a program. It does not specify in detail how P (a program) is realised, but it does specify a slice of its properties which may be interesting to users. We may also call specifications models, since models are abstraction of behaviour, and properties are nothing but abstractions of programs behaviour to be realised.
And just as we need a good language to do sound, consistent and scalable programming, we need a good specification/modelling language to do sound, consistent and scalable modelling/specifications. The question is: how does a language for programming relate to a language for specification? And which kind of languages do we need for our present purpose? The first one is a general question, but is a basis to answer the second question which reflects our own present needs.
On these questions, let's think on in the next post (since it is getting long and I am getting hungry).
