RE: Relationship between regions and transitions
RE: Relationship between regions and transitions
In reply to Alessandro and Tony (below)
> -----Original Message-----
> From: email@example.com
> [mailto:firstname.lastname@example.org] On Behalf Of Tony Simons
> Sent: Monday, 11 December, 2006 15:26
> To: email@example.com
> Subject: Re: Relationship between regions and transitions
> In reply to Alessandro:
> > I need a clarification about the State Machine Diagrams. I have read
> > 2.0 Superstructure specification and I can't understand how the
> > between regions and transitions exactly works.
> > I have found the specification of a previous version of UML. Regions
> > not present and it explains the realtionship between StateMachine e
> > Transitions in this way:
> > "Transition Associations: Associates the StateMachine with its
> > Note that internal Transitions are owned by the State and not by the
> > StateMachine. All other Transitions which are essentially
> > between States are owned by the StateMachine. Multiplicity is
> > Anyway maybe this concept is still valid and the transitions are
> > by the top-level region, but it's not really well defined. Talking
> > region's associations the Specification 2.0 says: "Transition: The
> > transitions owned by the region. Note that internal transitions are
> > a region, but applies to the source state."
> > Is it correct if I consider that the transitions are contained by
> > top-level region?
> > Thank you.
> > Alessandro
> I think that the basic notion of a 'region' comes from the idea that a
> composite state may consist of one or more regions (more, if there are
> parallel substate machines). In UML 2.0 the notion of region also
> to relate to the extension of state machines, whereby you show an
> state in dotted outline as a region of interest in which further
> or transitions are defined. I would find it consistent to assume that
> the transitions of the top-level states exist within a top-level
> bounded by the top-level diagram.
First some terminology. This will be useful to describe differences
between UML 1.4 and 2.0. It is hard to find neutral terms, but here is
simple state - a state having no substates.
composite state - a state having substates. This is an abstract
category consisting of:
simple composite state - A state machine in a simple composite state
exactly one substate of that composite state at any
Referred to by Harrel as "or decomposition". Also
as "simple decomposition."
concurrent state - a composite state having two or more orthogonal
A state machine in a concurrent state is
simulaneously in all
of its components. In essence the components run
Each component is usually further subdivided, i.e.,
contain the substates.
Referred to by Harrel as "and decomposition". Also
as "orthognal decomposition." Concurrent states are
referred to as "orthogonal states."
The orignal concept of region in UML 1.4 was restricted to concurrent
states. A region in UML 1.4 corresponds to an orthognal component of a
concurrent state above. UML 1.4's handling of composite states and
regions was however a bit clumsy. Regions were actually defined formally
as a kind of composite state (see derived property isRegion on metaclass
CompositeState). Essentially, a region is a composite state that is
directly owned by a concurrent state. Here is a mapping of the above
terminology to UML 1.4 state-machine metamodel elements.
simple state - instance of metaclass SimpleState
simple composite state - instance of metaclass CompositeState with
isConcurrent = false.
concurrent state - instance of metaclass CompositeState with
isConcurrent = true.
The immediate substates of a concurrent state are
instances of CompositeState.
These (composite) substates are called regions.
UML 2.0 refactored the metamodel to make region a metaclass. However, a
region is no longer restricted to being an orthognal component. A region
in UML 2.0 is essentially a way of collecting a bunch of states and
transitions. It is more of a structuring concept than a semantic
concept. UML 2.0 also got rid of the metaclasses SimpleState and
CompositeState. Here is a mapping of the terminology above to UML 2.0
state-machine metamodel elements:
simple state - instance of metaclass State owning no regions.
simple composite state - instance of metaclass State owning exactly
concurrent state - instance of metaclass State owning two or more
This makes for a uniformly easy way of distinguishing the concepts and
eliminates the clumsyness of UML 1.4. However, it has demoted region
from a semantic concept to a structuring concept. The notation, however,
has not changed. The orthogonal components of a concurrent state are
shown by subdividing the state using straight, dashed lines.
Regions have nothing to do with extension in the sense mentioned by Tony
above. An inherited state in a specialized state machine is shown as a
state with a dashed or grey-toned boundary. I would prefer the
grey-toned boundary because then its meaning is clear and you won't
confuse an inherited state with a region. But then again, a region is a
straight, dashed line dividing a state. Most tools will probably use a
dashed outline because it is may be easier to render and it shows up
better when all you have is black and white. (Interesting combination: a
region in an inherited state would be a straight, dashed line dividing a
state with a dashed boundary!).
On to transitions.
In UML 1.4, internal transitions are owned by states. All other
transitions are owned by the state machine.
In UML 2.0, all transitions are owned by regions. The specification is
not specific about which transitions can (or must)be owned by which
regions. You cannot, however, assume that all transitions are owned by
the top-most region. One rule of thumb would be that a transition
between two states is owned by the "closest" region that contains both
states. If you think of states and regions constituting a containment
hierarchy, then the closest region would be the least common ancestor
(LCA)of the source and target states in that hierarchy. You can find a
description of LCA in the spec. This appears to be the rule used by
Rational Software Architect version 6.
It is not clear to me that the prose description of internal transitions
in the UML 2.0 spec has quite caught up with the new ownership by
regions. For example:
"An internal transition executes without exiting or re-entering the
state in which it is defined."
This quote is verbatim out of the UML 1.4 spec. But internal transitions
are no longer defined within a state in 2.0. In general, it appears that
many sections of the description for state machines in the UML 2.0 spec
were copied verbatim from the 1.4 spec without really being updated.
There are a number of glaring inconsistencies and outright errors.
The most confusing thing to me is that an internal transition of a
simple state must be owned by a region containing that state (because a
simple state does not itself have a region). The most obvious thing to
me would be to have an internal transition owned by a region that in
turn is owned by the state. However, the state would no longer be a
simple state (it becomes a composite state without any substates!). So
simple states cannot own directly or indirectly their internal
transitions. And there is no constraint that says the source and target
of an internal transition must be the same state. Apparently it only
matters which state is the source state. And the term "internal
transition" is also used in the context of entry and exit points, in
which case it appears to have an entirely different meaning. These
issues have not been cleared up in the UML 2.1 spec either. Some of them
have been posted to the OMG for clarification.
Earl Waldin tel: +41 31 828 9222
Paranor AG fax: +41 31 828 9299
Juraweg 14 email: earl dot waldin at
paranor dot ch
> To remove yourself from this list please mail
> with a message containing the word "unsubscribe".
Received on Mon 11 Dec 2006 - 18:52:13 GMT