- From: Mayilraj Krishnan <mkrishna@cisco.com>
- Date: Mon, 03 Feb 2003 12:41:26 -0800
- 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. > ><Ricky> > 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. ></Ricky> > >(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. > ><Ricky> >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. ></Ricky> ><Mayilraj> 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. </Mayilraj> >That is the reason I view better to model the external (abstract) behavior >using activity diagram. >Notations: >Activity Diagram State Transition >----------------------- ---------------------- >Action Simple State >Activity State >fork/join fork/join >transition transition > ><Ricky> >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. ></Ricky> > >You can not define the swimlanes (does not have semantics in UML) in state >transition >but the roles representation is clear using swimlanes and can be easily >visualized in activity diagrams. > ><Ricky> >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"). ></Ricky> ><Mayilraj> 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. </Mayilraj> >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 >diagrams. >If you remove the states, actions, transitions from the state machines it >becomes flowchart. > ><Ricky> >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 ?? ></Ricky> ><Mayilraj> 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". </Mayilraj> >Best regards, >Ricky >
Received on Monday, 3 February 2003 15:43:33 UTC