Fwd: Re: Re: Non-determinism in Statecharts



Date view Thread view Subject view Author view Attachment view

From: Andrzej Wasowski (andrzej_wasowski@yahoo.com)
Date: Mon 20 Sep 2004 - 11:49:18 BST


I have (mistakenly) sent the following reply to Les personally. 
Forwarding to the list.

Andrzej

> Hello,
> 
> Instead of replying, I will insert several confusing comments.
> 
> > My answer would be, that the order in which the actions are
> > listed is irrelavent. Any action could be executed first. 
> > 
> > This raises the question: 'How do I indicate an ordered sequence
> > of actions on a transition?'
> 
> I actually used to think that in UML the order of actions on
> transitions does matter, considering UML to be much closer to a
> programming language, than for instance original Harel's statecharts.
> 
> But I have to admit, that I have never thorougly studied the specs to
> confirm that.  As a matter of fact I suspect that this is left
> underspecified in the OMG specs [anybody correct me if I am not
> right].
> 
> At the same time tools clearly enforce determinism: I have not heard
> of
> code-generator that executes actions on transitions in any other
> order
> than written (even if reordering would lead to some interesting
> optimizations).  I am actually trying to exploit this in my code
> generetor right now, but no materials are really available yet.
> 
> Finally, I think, that what UML specs actually enforce is the order
> in
> which generated local events are processed.  Contrary to synchronous
> languages (Argos, perhaps, being syntactically the closest one to
> statecharts), in UML run-to-completion step seems to guarantee that
> current event is processed entirely, before any local signals
> generated
> in the step are processed.  
> 
> This can be used to enforce execution order in nearly all variants of
> statecharts.  If you want g() to be executed strictly after f(), then
> put f() on a transition together with a generation of temporary
> event,
> which fires an internal rule or transition somewhere, that has g() as
> its action.  I have seen actual models of embedded systems using this
> principle, altghough I find it somewhat heavy.  It has another
> advantage of circumventing,  double-buffering variables, an otherwise
> useful semantic feature, which separates the rvalues and lvalues of
> variables, making the effect of the assignments visible only after
> the
> step is completed.   I know some statecharts variants support it, I
> am
> not sure how about UML. Perhaps underspecified again.  
> 
> Note that this feature is also related to nondterminism.  In general
> double-buffering reduces the nondeterminism of the model, as the
> order
> in which transition guards are evaluated is insignificant (unless
> they
> dependent on calls to external impure functions).  Finally if there
> are
> no external calls in th actions themselves, then the order of actions
> on the transitions becomes insignificant, as you write.  But wether
> UML
> actually means that, I fail to know with certaintity.
> 
> There was a PhD thesis by Erpenbach written in Germany that tried to
> exploit commutativity of actions in presence buffering, to reduce the
> amount of data management needed to implement this feature, so I was
> not entirely right, when saying above that I have not heard of code
> generator reordeiring actions.  Erpenbach's code generator is the
> only
> one I have heard of, which does this.
> 
> Not that this answers anything, but perhaps sheds some light on
> semantic variations related to nondeterminism in statecharts.
> 
> Andrzej
> 
> 
> 
> 	
> 	
> 		
> ___________________________________________________________ALL-NEW
> Yahoo! Messenger - all new features - even more fun! 
> http://uk.messenger.yahoo.com
>  


	
	
		
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun!  http://uk.messenger.yahoo.com

Date view Thread view Subject view Author view Attachment view