Re: [UML Forum] Activity diagram - multiple output flow

[Remy Fannader]

If there is no constraints on flows it should be a fork
Remy

On 25 November 2012 17:10, Tomas12 <tom....@gmail.com> wrote:

Hi everyone,

Could anyone help me with the following issue?

Can I have multiple output flow from one action in an activity diagram without using either decision node or fork node.

In case of using multiple output flow without the mentioned nodes, is it parallel (as fork) or sequential (as decision node) flow?

Is it correct to not use either decision nod or fork node according to UML specification 2.1.

I can not find any answer in the UML specification.

Thank you for your help in advance.

Tomas

--
You received this message because you are subscribed to the Google
Groups "UML Forum" group.
Public website: www.umlforum.com
To post to this group, send email to umlf...@googlegroups.com
To unsubscribe from this group, send email to
umlforum+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/umlforum?hl=en?hl=en

[Cedric Gava]

Hi thomas

I would say that It dépends :
If the flow is control flow, then you can put as many output flow as you want. When the action complètes its exécution, on token is put on each control flow

For object flow, you can only put one flow for each output parameter of your action...

Example : your action calls an opération with à return and 1 ouput parameter, then you have two ouput pin, one for each...
AFAIK, if you want to "duplicate" à flow, you have to use a fork after your pin.
If you use multiple flow from the same pin, then the target nodes competes for the token : the first executed consumes the token (It is not à fork, and not à décision... )

Good luck
--
Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.

Tomas12 <tom....@gmail.com> a écrit :

[h.la...@verizon.net]

You should use a fork. Historically the AD is schizophrenic; originally in UML it was a kind of state machine. But it also had features of Data Flow Diagrams. One of the hard-won lessons of the '60s was that procedures (aka atomic processes)  should have a single entry point and a single exit point. There is also the general OO notion that behaviors are not aware of context and any messages sent by the behavior are simply announcements of  what it did. Therefore, any routing of announcement messages should be donw outside the behavior (e.g., explicitly defined in a fork that is separate from the process itself). IOW, one deals with communications between processes explicitly at a different level of absrtraction (forks) than one deals with defining the behaviors (AD processes) themselves.

 

 

 

Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer

[Ashley at Metamaxim]

> If there is no constraints on flows it should be a fork

I think it is not quite as easy as that. Suppose that you have three output flows: A, B and C. Suppose that A and B are mutually constrained and that B and C are mutually constrained; but that A and C are not.

This situation is describable in process algebra as:

(A+B)||(B+C)

where + means choice and || means CSP style parallel composition. 

But I don't think that this is describable using forks and decision nodes (unless you are prepared to dispense with possibility that A and C can happen simultaneously).

Rgds
Ashley

[h.la...@verizon.net]

You will have to wait until 12/6 for a detailed reply when my computer gets back from depot repair. Between my wife's El Cheapo laptop and my ISP's user vicious web site, it is agonizing to reply (e.g., I can see only one(1) line in the conpose window. However, I have a couple of quick points...

 

 

(1) An OO process only generates announcements of what it has done and that is completely determined internally by the process logic, so all the fork handles is where the  message goes IF it is present, not whether it is issued.

 

(2) I think the kinds of constraints you are implying would be more appropriate in the Class Diagram on relationships or in an Interaction Diagram, particularly the latter beause that is where one is supposed to describe inter-object communications.

 

(3) I think you can express your constraint with multiple forks, given (1) above.

 

Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer

 

[Ashley at Metamaxim]

Hi H.S.

> (3) I think you can express your constraint with multiple forks, given (1) above.

What would it look like?

Hope you get your computer back soon!

Ashley

[Cedric Gava]

Hello

Sûre there is à mention about It : the target nodes compete for the tokens going out trough multiple flow.

--
Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.

Tomas12 <tom....@gmail.com> a écrit :

Is there any mention in the UML specification about the multiple output flow from an action without any fork or decision node?

Thanks,

Tomas

Dne úterý, 27. listopadu 2012 17:26:31 UTC+1 H. S. napsal(a):

[h.la...@verizon.net]

I'll draw a picture next week when I get my machine back. There is just no way I can face doing that in my current setup. 

 

 

 

Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer

 

On 11/27/12, Ashley at Metamaxim<ashley....@metamaxim.com> wrote:

 

Hi H.S.

> (3) I think you can express your constraint with multiple forks, given (1) above.

What would it look like?

Hope you get your computer back soon!

Ashley

On 27/11/2012 16:21, h.la...@verizon.net wrote:

[H. S. Lahman]

Responding to Ashley,

Hi H.S.

> (3) I think you can express your constraint with multiple forks, given (1) above.

What would it look like?

Hope you get your computer back soon!

Alas, not so soon. It was irrepairable so Dell gave me a new one. However, it took me until now to salvage the data. Therefore this is a little late.

Your original proposition was:

"This situation is describable in process algebra as:

(A+B)||(B+C)

where + means choice and || means CSP style parallel composition."

I think that whether is can be expressed with forks depends on what you mean by 'parallel composition'. If we mean that the process will always generate a B event with either an A event or a C event, then I would argue that such a constraint belongs inside the process. That is, the business rules and policies the process implements determine whether A or C should be issued at all and those rules will already handle this constraint so that all we need to do is route A, B, and C correctly in the AD without any forks.

OTOH, if this is a routing constraint when we always have A, B, and C being generated, then I think forks can be used. All we really need to express that B goes to two places is something like:

<pre>
    A               B                C
    |               |                |
    |               |                |
    |             =====              |
    |              | |               |
    |  +-----------+ +-------------+ |
    |  |                           | |
 <A locations>                 <C locations>
</pre>

-- 
Life is the only flaw in an otherwise perfect nonexistence
   -- Schopenhauer

Imagine how much more difficult physics would be if electrons had feelings
   -- Richard Feynman

Rene Descartes went into a bar. The bartender asked if he would like a drink. Descartes said, "I think not," and disappeared.

H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html