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...