W3C home > Mailing lists > Public > public-ws-chor@w3.org > February 2003

Re: Same model for both Public and Private process ??

From: Mayilraj Krishnan <mkrishna@cisco.com>
Date: Mon, 03 Feb 2003 12:41:26 -0800
Message-Id: <>
To: Ricky Ho <riho@cisco.com>
Cc: public-ws-chor@w3.org

At 11:21 AM 2/3/2003 -0800, Ricky Ho wrote:
My comments are embedded.

>Mayilraj, thanks for your response.  My comments are embedded
>The external behavior can be modelled in both activity and transition 
>diagram always.
>(1) State Transition Diagram
>Each action is taken when events are detected by the state machine. Action 
>will get the inputs by the event.
>Here emphasis given more to the states of objects and transitions of the 
>states. In practice UML recommendation is
>also to model the reactive objects(normally single)  by state transition.
> From the perspective of "external behavior", I think the emphasis should 
> be in "events", "transitions", "states".  I'm not sure about "action" 
> because it seems to be exposing private implementation of how a party 
> respond to an event.
>(2) Activity Diagram
>Each action is taken when previous actions are completed or all the 
>required inputs are available for the object.
>Here emphasis given the order in which the actions are taken.
>Following my above argument that "action" is private implementation 
>details, then the emphasis in "the order of actions taken" is certainly 
>undesirable from a "public behavior" perspective.
I agree "action" is private implementation details. But activity diagrams 
can represent the activities as well.
Action is atomic execution and activity could be non atomic execution.
Example: Process Order is an activity.
Validation, Availability Check are actions.
Partly this answers your previous question as well.
>That is the reason I view better to model the external (abstract) behavior 
>using activity diagram.
>Activity Diagram          State Transition
>----------------------- ----------------------
>Action          Simple State
>Activity                State
>fork/join               fork/join
>transition              transition
>I have a different opinion.  It seems to me that an "ARC" in the state 
>transition diagram should correspond to a "NODE" in the activity 
>diagram.  On the other hand, an "NODE" in the state transition diagram 
>should correspond to an "ARC" in the activity diagram.
>You can not define the swimlanes (does not have semantics in UML) in state 
>but the roles representation is clear using swimlanes and can be easily 
>visualized in activity diagrams.
>I think it is easier to extend the "event definition" of the "state 
>diagram".  E.g.  (Event is always "role X is sending a message M to role Y").
The point  is event producer (role) notation missing . (No swimlanes 
notation in state transition
diagrams). Since it does have semantics you can always extend the usage in 
state transition as well.

>I guess I'm talking about the opposite.  I think a "private process" is 
>richer than a "public process".  By taking away the "process variables", 
>"conditions", a "private process" will become a "public process".  Is that 
>true ?
>Here I agree with Asraf comment "The fine line between  public and private 
>process  is computation intensive nature".
>I think this computation intensive only you are calling richness. In that 
>case yes, private process is richer than public process.
>But if it is not computation intensive I don't know why we have to model 
>the operation using activity or state transition
>If you remove the states, actions, transitions from the state machines it 
>becomes flowchart.
>I don't understand here.  What is left after removing states, actions, 
>transitions from the state machines ?  How come it turn into a flow chart 
>?  An example ??

Good catch. Please read as "If you remove the transitions, forks/join from 
actions or states in the state machines
it becomes flowchart when you model an operation".

>Best regards,
Received on Monday, 3 February 2003 15:43:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:29:54 UTC