Re: Statecharts properties



Date view Thread view Subject view Author view Attachment view

From: Andrzej Wasowski (andrzej_wasowski@yahoo.com)
Date: Thu 15 Apr 2004 - 09:50:23 BST


Hi,

 --- Les Munday <baldrick@ureach.com> wrote: 
> > Two concurrent states operate synchronously, whereas messages
> sent
> > across statecharts may be treated asynchronously (put in some
> queues). 
> > 
> And this can't happen if they are in a single statechart
> diagram? I believe the diagram makes no difference to what can
> be shown, by simplifying makes it less complicated, but then you
> have two diagrams to look at instead of one. Your choice which
> makes the better presentation.

I was not saying what is a better modelling practice. I was rather
commenting on the fact that having concurrent components and
concurrency at the object level are not necesserily semantically
equivalent. The official UML semantics is a bit messy (or blurred if
you prefer) to state this firmly. The attempts to formalize it that I
know of, would usually make a difference between the two types of
concurrency, by requiring a completely synchronous behavior on a
diagram level, but not on inter-object level. Thus if any local events
are in the queue, these events have to be processed before any external
event is responded to. In such case the translation you propose is not
sound.

Again this does not mean that one modeling way is better than another.
In fact both are useful for various things. Concurrency in states is
useful to model components with bounded but dynamic concurrency, i.e.
with dynamically changing number of processes, but only in some
predefined finite way. Concurrency on object level can be used to model

systems with unbounded numbers of processes (via object allocation) or
to model systems with fixed number of processes. The downside of object
side is that so far there are not many good ways to analyze it formally
and automatically (since these are potentially infinite state systems).

> I have always been under the belief that an object can only be
> in a single state at any moment in time. If my assumption still
> holds, then your concurrent states in a statechart diagram
> cannot be applied to classes in a class diagram .. i.e. you'll
> have to break them out and allocate to separate classes.

This is a misunderstanding. An object still remains only in one state,
but the state of the object is a complex entity. Let me explain this
way: During program execution the state of the object contains the
values of variables (local environments), usually more than one.
"Diagram" states are no different than a bunch of discrete, finite
domain variables and they also belong to that state if you wish. This
part of state is often referred to as a state configuration.

An object cannot be in two configurations at the same time in this
terminology. Basically we are confusing syntactic and semantic terms.

regards

Andrzej


	
	
		
____________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html

Date view Thread view Subject view Author view Attachment view