But how come? Why nobody has a dispute? Well signature in OOPLs or functions is a minimum structure by checking which it is guaranteed that your program can run without type error (assuming the lack of hardware/OS/null-pointer.. errors which we cannot completely take off). So if your program invokes methods following their signatures and in turn these methods do the same (this is a recursive definition) then all should end well --- as far as type error goes.
A model (in the sense of UML class model) is different. For example consider a natural constraint that a class only has a single instance: this is easy to specify and we do often specify in class models: but Java does not have it as part of its type structure, indeed its realisation as a code is that you restrain the behaviour of its constructor: it is declarative at the model level but it is operational in its realisation.
This is the same as how the collection of instances of two classes relate in numbers and many other such specifications: but these specifications are useful in models if their realisation as a code is messy.
And this is a good thing: all such constraints and specifications at the model level are usually easy to impose as far as we consider disciplined programming (or we can indeed do MDA); further, at the level of models, we may wish to describe many features which are not too detailed operationally --- in fact even those features whose realisation may not be uniquely determined behaviourally such as:
"This program will return an even number regardless of its input"or
"In this conversation Alice may speak to one of her boy friends"that is a model can be non-deterministic even though our target behaviour is deterministic. Also the distance between models and programs allows extensions at the level of models more easily than without. And when a model is sufficiently constrained or restricts its concern to structural properties then semantic gap can usually be filled using APIs and other semantic layers.
* * *
For some time we have been and we shall be focusing on signatures, not models, in this blog, though we may discuss (as a preparation) models and behavioural specifications in some cases (behavioural specification corresponds to say UML action semantics). So while I am sure some may find what is being presented a bit too simple and too terse please wait.
However signature is already quite rich in its power of description: it has repetition (loop), choices (and you have some choices as to choices), parallel, inner conversations, recursive conversations, sequencing, even merging. The signature offers building blocks for the whole description languages including DbC in the present context: so we shall have a plenty to see for some time.
And then we shall move to what corresponds to class models (called conversation models): and then we shall move to behavioural description. And all this is as dictated on the Sixth Day (which is recorded here).
