RE: statecharts and activity diagrams



Date view Thread view Subject view Author view Attachment view

From: Chris Britton (chris.britton@blueyonder.co.uk)
Date: Sat 05 Oct 2002 - 16:56:36 BST


I can think of three reasons why activity diagrams are preferred to
state charts in businesses:

1. Activity diagrams give more of a sense of flow, especially if they
are drawn going left to right or top to bottom. Flow is important in
analysing processes. To analyses a process by cost, error rate or
duration, you need to look at each step. It seems natural to break down
the analysis by task but unnatural to break down the analysis by state.

2. State charts "feel" as if they should be implemented by a single
object but many processes are implemented by the movement of data which
fits more naturally into the activity diagram presentation.
 
3. It is easier to bend activity diagrams to break the rules - as you
have noted. Say for instance I want to express the situation where I
have 4 tasks to do but I don't care which order they are done in. This
is very common. For instance, when inputting an order you need to put in
the delivery address, the payment details, customer identification and
the order line details but it makes no difference what's done first. I'm
sure this can be expressed in state charts but I for one am not sure how
to do this in a way that is easy to read. (I would be very interested in
knowing if there is a good solution to this problem.) With Activity
diagrams it's easier to extend the UML or add a comment to say what you
mean.

In business, models are more often used as a form of communication
rather than as an analysis tool. All of the above are about making it
easier to explain the design to others many of whom don't understand or
care about UML.
 
Best regards,
Chris

-----Original Message-----
From: puml-list-request@cs.york.ac.uk
[mailto:puml-list-request@cs.york.ac.uk] On Behalf Of Esha Ray
Sent: 04 October 2002 20:21
To: Rik Eshuis; puml-list@cs.york.ac.uk
Subject: Re: statecharts and activity diagrams

Another thing came to my mind, everywhere Iread that statecharts are
better
for modeling embedded systems and activity diagrams for business
modleing.
The question arises is why, what is it we lose when we do the other way
round?

I will really appreciate any help/clarifications
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
>
>
>




To remove yourself from this list please mail
puml-list-request@cs.york.ac.uk
with a message containing the word "unsubscribe".

Date view Thread view Subject view Author view Attachment view