Re: statecharts and activity diagrams



Date view Thread view Subject view Author view Attachment view

From: Esha Ray (esha@laser.cs.umass.edu)
Date: Fri 04 Oct 2002 - 19:48:10 BST


Rik, Thanks for all the information. I am looking at your thesis to get a
clearer picture. I had another question , if anyone else reading this will
know the answer then do write back.
To model a system do we lose anything if we don't use actvity diagrams and
use statecharts or in other words is there anything special in activity
diagrams which will make them better to model a system. Somehow, statechart
semantics are more clearly defined than activity diagrams so we were having
a debate.

-Esha

----- Original Message -----
From: "Rik Eshuis" <eshuis@cs.utwente.nl>
To: <esha@wedgwood.cs.umass.edu>
Cc: <puml-list@cs.york.ac.uk>
Sent: Friday, October 04, 2002 9:16 AM
Subject: Re: statecharts and activity diagrams


> Hi Elsa,
> >
>
> > We have been hearing stuff about the ambiguious semantics of the
> > activity diagrams. Statecharts semantics are more clearly defined
> > than activity diagrams. UML manuals say that activity diagrams
> > are a specialised form of state diagrams. We were having a number
> > of questions regarding this.
>
> My Ph.D.thesis "Semantics and Verification of UML Activity Diagrams
> for Workflow Modelling", which I just completed, may be interesting
> for you. It addresses some of your questions, from the perspective
> of workflow modelling. You can download it from
>
> http://wwwhome.cs.utwente.nl/~eshuis/thesis-hyperlinks.pdf
>
> Let me now give an answer to the more general question:
>
> What is the difference between activity diagrams and statecharts?
>
> There is a difference between statecharts and activity diagrams
> in syntax and semantics.
>
>
> Syntax:
>
> Activity diagrams have no hierarchy constraints, but statecharts have.
> Due to these constraints, the concurrency you can express in a
> statechart is limited, compared to an activity diagram. For example,
> it is possible to write down an activity diagram that has unsafe
> behaviour, i.e., there is a node that is active more than once at the
> same time, whereas this is impossible in statecharts. In terms of
> Petri nets, activity diagrams correspond to Petri nets, whereas
> statecharts correspond to a subset of safe Petri nets.
>
> In UML 1.4, activity diagrams are given a semantics by translating
> them into statecharts. UML 1.4 therefore has to rule out certain activity
> diagrams, because they cannot be translated into statecharts. See
> Section 9.1 of my thesis for examples and more details. UML 2.0 will
> define a semantics directly in terms of activity diagrams and therefore
> does not have to rule out activity diagrams. In my thesis, I have also
> defined the semantics directly in terms of activity diagrams.
>
>
> Semantics:
>
> The UML 1.4 semantics of activity diagrams is defined in terms of UML
> statecharts. In my thesis, I have given a UML statechart-like semantics
> to activity diagrams, as well as a Harel/STATEMATE like one, and proven
> that the two are similar for certain properties. With statechart-like, I
> mean that I have used the design choices of UML/Statemate statecharts in
> my two semantics, without translating an activity diagram into a
> statechart. So I allow all the activity diagrams that are ruled out by
> UML 1.4.
>
> On the key proposal for UML 2.0, the one of the U2 partners, defines a
> semantics for activity diagrams in terms of a Petri net token-game
> semantics, i.e., there are tokens flowing on edges.
>
> The main difference between a Petri net token-game semantics and a
> statechart semantics, is that the statechart semantics is reactive,
> whereas the token-game semantics is not. With reactive, I mean the
> following:
>
> (1) transitions of a statechart are triggered by events from the
> environment outside the statechart. In a Petri net, there is no notion
> of triggering: if a transition has enough tokens in its input places,
> it can fire. There is no notion of environment in a Petri net token-game
> semantics.
>
> (2) an enabled (triggered) transition in a statechart MUST be taken,
> whereas an enabled transition in a Petri net MAY be taken. So, in a
> Petri net, knowing that a transition is enabled does not tell you whether
> or not the transition will be taken: the system can decide itself to
> postpone taking the transition, so the system is active rather than
> reactive. Whereas in a statechart, once a transition is enabled, the
> system must take it, and cannot postpone it: the system is reactive.
>
> Section 4.2 of my thesis explains this in somewhat more detail.
>
> The Petri net fans will of course say that reactivity can be simulated
> in Petri nets. Well, I don't agree, and I have used a whole chapter
> (Chapter 8) in my thesis to explain why I don't agree. I have looked
> at a whole variety of Petri net semantics. Chapter 8 will also
> appear in a LNCS volume on Petri net-based workflow modelling, so it
> has been heavily refereed by the Petri net workflow community.
>
> I think the U2 partners decided to use a token-game semantics for
> activity diagrams, because the syntax of activity diagrams, without any
> enforced hierarchy constraints, looks like the syntax of Petri nets.
> (See Section 8.7 of my thesis.)  In my thesis, I have shown, however,
> that it is also possible to define a statechart-like reactive semantics
> for a notation with a Petri net-like syntax.
>
> These are in my opinion the major differences between activity diagrams
> and statecharts.
>
>
> Best regards,
>
>
> Rik
>
>
>

Date view Thread view Subject view Author view Attachment view