Modelling Objects, Modelling Processes (2)

Well I am starting to write this at 2:25 so I will be brief today. The following account is based on what I learned from David's draft discussions on the metamodel for UNIFI 2.0 even though my understanding may still be shallow. Communications from Matthew (especially his Pierce interpretation of message delivery) have also given me a fertile ground to start from.

And yet another source, an experience --- today I saw a piece of software which is up and running and which I may call the first genuine conversational/session programming working in the real world (not my creation). It is not only working: it is superbly working with every bit fully working. But on that perhaps a month or so later.

* * *

We were discussing about how we position processes

As I wrote last time if we wish to have a foundational model then we start from a process and its specialisation being an object.

So a class model will be about a process (or let us call it a conversant) and if a conversant is so special as to have only call-return then it is an object.

This works of course. But if two communicate they need messages. These messages are mostly passive (this is not the pi-calculus view: but is a practically relevant view I believe).

And components of these messages may as well be described by class models.

This is one of the reasons we may start from objects and classes. Then a process which converses should be a special kind of an object. That is

some objects are also engaged in "conversation". They may be called conversational objects.

A conversation is different from method invocation since it uses a channel: moreover we assume there are another "thread" in the interacting party and they converse even though they can interact in the "co-routine" fashion.

Note the idea of conversational objects above conforms to Maxims 1--3 we discussed in the preceding post.

Now an object can be engaged in a conversation as a result of being invoked: and an object can also be invoked in a conversation when it is born --- automatically after its "initial state" (in the state diagram sense).

Suppose Alice, Bob and Carol are conversing. A message Alice sends should belong to a class which Bob understands. That is there should be a class model which encompass both Alice and Bob --- or at least we wish to have signature (structure) compatibility.

OK so we have some picture. This can be written as a diagram. I did not start from a "user" in UML (though this is natural). Here a "class" can be considered as a "participant (actor) in a role". We may as well wish to have a company like Amazon in this picture. Say this is a rectangle part of a UML use case diagram (that system with which a User interacts). Then where is a rectangle?

Well why not to have a rectangle? Put it around Alice. Note Alice is now a class: so its instance converses and perhaps we can colour Alice since it is a conversational object. In many cases (if we use conversations for programming-in-the-large) this object may as well be an object which only does a conversation and no method invocation any more (Alice has this to say: "I do more complex things now so how can we go back to that simplistic model even though I do have nostalgia"). Perhaps we can colour its border with orange to say it is a class for a conversant object.

I will upload some diagram (hand drawn so please do not expect much) which shows an instance of this. For now note that we have here

• three rectangles (participants)
• a specific class model for each which may be rather deep in hierarchy
  
• a common "shallow" model (or models) for messages
  

I do not wish to say this is one class model articulated with three "local enclosures" for each participant: in general we do not need a common class model even for message components even though this may be very useful in practical concerns and if we can afford this may be good to have (if you can easily have transparency in some cases why not to have it --- especially given one of our current primary applications is a meta-standard for different protocols).

So perhaps we may as well have a common class model for message components? Another thing which can be useful is a notion of a role which one can consider is a way to relate two conversational objects by saying "these guys are the same" or "these guys are essentially the same except wearing different colours" (say). Note however we need to write down a conversation between these two conversants: they are from the same template (they are instances of the same class) but when they converse they should converse as different persons.

One possible way (I do not say the best, we need more examinations) is to have a class model and consider about "using" one class in two participants --- by sort of projecting relation. This means we can also make two roles related by a class hierarchy.

This means we can have the following different kinds of class models in our conversation diagram:

1. Individual class models for each participant (deep)
   
2. Common class model(s) for message components (shallow)
3. Common conversational class model(s) for common or related roles (shallow)
   

At this point I do not know how useful 3 above can be: that point as well as all points including the basic setup, we shall examine from now on through use cases.

Today I will finish here. In the next post --- perhaps tomorrow --- we shall think about how we can adapt several standard diagrams for conversaitons, starting from tje use case diagrams.

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.