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.