Activity Diagramming Question

[JocaRamiro]

I could use some aevice on the preferred way to handle decisions and control flows within Enterprise Architect's implementation of the UML activity diagram.

1) if a decision requires input from two activities, is it good form for there to be two flows into a decision diamond or should a fork/join bar be used?

2) if one of the outcomes from a decision leads to two separate activities, is it good form for there to be two outgoing flows or should a fork/join bar be used?

I have assumd both answers to be YES, and produced a diagram  which I can't quite represent.  Is there a better way?

Mead Walker

[Eve]

You've assumed YES to which options that you've specified for each question?

1) From memory, a (merge) diamond will be activated as soon as one input control flow present.  In contrast, a join bar will be activated only when all input control flows are present.  As such I would say that there should be a join bar followed by the decision diamond.

2) I'm not sure if there is a constraint on a decision diamond that specifies that only one path is taken out of it.  (Just that it sounds like a condition that would match what I remember from the inputs.)  If I'm correct in this then you would need to model the decision diamond followed by the fork bar.

Having said that, there are also precedents for shorthand constructs. (eg. diamonds acting as both merge and decision) If you're model isn't going to be executed by a tool that will strictly follow these rules, then feel free to do whatever shows what you need it to.

[Jan ´Bary´ Glas]

Merge - doesn't stop the flow, the token is just passed. So only one input is enough.
Decision - doesn't stop, but only one flow is run. Be careful to define the condition well (the best is logical sum of "1")
Fork - more outgoing flows are going out at once
Join, action, activity - waits for all incoming flows to be filled.

That's for UML 2.x

[JocaRamiro]

Thanks to both responders.  This has been helpful.  I also have to thank you for capturing what I was trying to ask, even though my question turns out to have been rather poorly written.

Just to confirm one thing that Jan said: It looks like UML merge and decision boxes look identical.  Do I indicate something is a merge by giving it a text tag "merge".  Is there any objection to having more than two streams merge?

Mead Walker

[«Midnight»]

Not sure and no, respectively.

[KP]

It looks like UML merge and decision boxes look identical.

No they don't: A merge node has multiple in-flows; a decision node has multiple out-flows. Easy to tell them apart

[Paolo F Cantoni]

No they don't: A merge node has multiple in-flows; a decision node has multiple out-flows. Easy to tell them apart

Especially when the flows go in an out of the same symbol...

The [size=13]UML 2.1.1 Superstructure (formal)[/size] Specification in Figure 12.76 - Decision node notation shows: "Decision node and merge node used together, sharing the same symbol".

Paolo