My quick stab at the question inserted below.  I am hoping your question provokes some further discussion.

--- In executableuml@yahoogroups.com, "Ashley McNeile" <ashley.mcneile@...> wrote:
>
> Hi All
>
> Some time ago, I posted a question (message 704) to this list about
> Determinism/Non-Determinism in Executable UML, which Marc was kind
> enough to answer (message 705). In my question I described a very
> simple model and asked whether its behaviour was deterministic.
> Marc's answer was that it was not.

I think the confusion may center around the precise subject to which the term "deterministic" applies.  Executable UML state models are deterministic.  An instance in a state has only one place to go for any arriving event.  But I don't think that's what you are talking about.

As we increase the scope the story changes.

>
> I was puzzled, therefore, to see that the Wikipedia entry for
> Executable UML (http://en.wikipedia.org/wiki/Executable_UML) says in
> its introduction that "Executable UML graphically specifies a
> deterministic system using a profile of the UML". This does not seem
> to agree with the conclusion above.

So now we are talking about a system.  That's kind of a loose term, so let's set the scope to a populated Executable UML domain.  This applies to the example in messages 704 and 705.  Marc's answer in 705 is correct.  Since we don't know the timing characteristics of the platform, we can't guarantee that a posted signal was acted upon by the receiver before the query is applied.  But does that make the domain non-deterministic?  Marc says "yes".  But maybe that misses the point, given this latest question.

If I were building a system and I wanted to know whether or not the receiver had processed my signal before moving on, it would be easy to do using deterministic state machines.  The sender would either advance to a waiting state, or stay in the current state until a "Got it" event occurs.  The receiver would process the original request as time permits and, upon completion, post the corresponding "Got it" signal.  Upon seeing the "Got it" event, the sender would know, definitively, that the request had been processed.  (There are other techniques, but the point is that there is an explicit interlock with resulting determinism with respect to the model execution rules).

So explicit synchronization, guranteed to work on any arbitrarily distributed platform, is possible.   The challenge of the modeler is to decide when synchronization is and isn't necessary.  Sometimes you don't care when a requested action completes and sometimes you must somehow block until it does.
>
> My understanding is that Executable UML models are, in general, non-
> deterministic. However, there are probably rules that can be appplied
> to the formation of a model that guarantee that it is deterministic.

Maybe another way to put it is to say that synchronization is never implicit.  By default each object does its own thing in parallel unless explicitly sequenced internally or synchronized with some other object or external entity.  A really cool thing not advertised enough about Executable UML!  Every time I see some article on Slashdot about how we need some kind of language for specifying parallel behavior to support multi-core environments my head explodes.

> As far as I know, these rules have never been articulated.

Funny you mention this as I have been working on an article the last couple of weeks on this exact topic.  I hope to publish it as a Google Knol (knol.google.com, search on Leon Starr).  It will have many colorful illustrations and animations.  The current working title is "Timing and Synchronization Rules in Executable UML".
>
> Is the Wikipedia entry assuming the existence of such rules? If so,
> have they been articulated anywhere?
>
> Or is the Wikipedia entry wrong?

I don't think it is wrong, but the statement is not terribly informative. It probably needs to be elaborated on a bit.  Hopefully the ensuing discussion here will give us the pieces we need to get it done.  I would be happy to post the results once we arrive on a consensus.  In fact, I was SHOCKED to see the that there was a Wickipedia entry on Executable UML.  Thanks for bringing it to my attention.

- Leon
>
> Thanks
> Ashley
>