Thursday 8 November 2007

Modelling Objects, Modelling Processes (1)

Modelling with capital M: that is what I am thinking here.

UML centres on objects (consider the class models, which are a lynch pin of this whole modelling framework). What are differences between objects and processes?

Not processes in any difficult sense: we need to think of them since they are the entities who converse. We are trying to describe conversations, so we naturally need to have the ontology of conversants --- if ever we want our modelling framework to be wholesome. It may also be better to be clear that I am not talking about "business processes" here even though it is closely related. I am talking about processes as a central concept in modelling: that is my discussions are purely from the viewpoint of modelling concerns. We need to position it as a fundamental notion for abstraction and modelling.

As Robin Milner observed in his recent short note, modelling is about explanation. So a process explains --- some behaviour, some structure. What is a process, what does it explain, how does it differ from an object?

It's better to start from a process. A process is an entity which interacts. Here "interaction" means it exchanges messages: it sends messages and receives messages. That is what a process does. And perhaps we want it to have its own state. So here is a simple definition:
MAXIM 1: A process is an entity with interactional behaviour and its own internal state.
The use of the term "interacitonal" may not be common, we can call it "interacting", I did not use the term "interactive" since this term may sound as if it is about human interaction. No, a process will usually interact with another process.

But this looks like quite like an object: what is a difference? An object has:
  1. attributes
  2. methods
And this second item carries an object's behaviour, doesn't it? Here we come to the first key difference between processes and objects:
An object may interact by method invocation and return; processes may interact with the outside in more varied ways --- it will have a series of interactions part of which can even be done in parallel but whose interactions as a whole form a meaningful structure.
In other words processes are engaged in a conversation: and patterns of conversations include, as a very special case, a method invocation and its return (including an exception return). That is
MAXIM 2: the behaviour of objects as we know of is a special case of that of processes: that is, an object is a special case of a process.
Note here I am exclusively taking the modelling viewpoint: of course a process may be implemented using objects, but that does not concern us in the present inquiry. Here we are trying to find steps towards an abstract entity which can be a basis of modelling the kind of software which predominantly consists of mutually and concurrently interacting software --- and perhaps the development of such a kind of software may become a lynch pin of software structuring methodologies in near future.

The modelling viewpoint demands us to stipulate --- make it exist --- the minimum essential structure of an abstract entity we are now struggling to build. Incidentally Maxim 2 offers us a hint: if so we need the same thing as an object in a process. How should it be named? Can it be something readable from the outside just as an attribute of an object? Or should it be strictly local to that process? But let's be conservative, we can change it later, this is anyway an experiment, we use the same term as an object:
MAXIM 3: a process has its attributes whose content defines the current state of a process.
Now this is a decision: and a necessary decision for that matter. And we have two more things to think given Maxim 3, answering (or trying to answer, let's be honest) the following two questions:
  1. Can a process get engaged in two or more conversations at the same time?
  2. How about messages? Perhaps messages consist of objects? Then don't you need objects before processes?
I will discuss these points tomorrow: for the time being I just give yes-no answers (which are not answers we are seeking but gives us a starting point at least): for 1 the answer is yes, and of course this necessitates us to think about shared mutual data. This is the concern treated in a corner of UML (so-called "active objects": on which there are a lot to discuss) but will become a basic concern from now on. Exploring this topic may need some time. For 2, again (and perhaps surprisingly) the answer is yes: we assume the existence of objects as our prerequisite. In fact conversations need messages and messages should be defined from some components. Well we could have started this discussion from messages as our expert colleagues are doing now in UNIFI.

But that will also be a topic we shall treat later. For now we finish this initial part of an exploration.