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.