How to design decision after decision (diamond) in UML?

Question

I am designing UML Activity diagram in ArgoUML now. I know that if I want to design condition like:

if(condition) {
    doTrueAction();
} else {
    doFalseAction();
}

It could be done in UML activity diagram like following:



But what if we have another condition inside the output of the previous decision? Like this:

if(condition) {
    if(condition2) {
        condition2TrueAction();
    } else {
        condition2FalseAction();
    }
}else{
    conditionFalseAction();
}

As you see conditionTrueOutput is being output and condition at the same time here. It seems to me that design is broken.

Edit: Or I should use fork element instead of decision (diamond) element?

I want to know how to design this correctly. Is there any rule?

Answer 1

There's a wrong assumption in your thoughts. A Decision has no output. It just has conditional control flows leaving it. Each can be guarded by a certain condition. This guard is written in square braces:

Note that I did not write the (implicit) [true] guard after the first test (rather by sloppiness when editing, but actually it can be omitted).

Edit My first though that your diagram has another flaw in that the actions have no control flow going out was incorrect. Actually Superstructures state that a missing outgoing control flow is equivalent to an FlowFinal after processing the Action. So your diagram is correct here.

Regarding your edit: as the comment says, this is for parallel continuation. Nested conditions need to be like shown above.

Edit2 As Ister noted in the comments, a Decision can have more than just the if and else control flow going out, but an arbitrary number greater than 1. The UML 2.5 states on p. 388:

If exactly one target of an unblocked outgoing edge accepts the token, then the token traverses the corresponding edge and all other offers are withdrawn. If multiple targets accept the token simultaneously, then the token traverses only one of the edges corresponding to the accepting targets, but which one is not determined by this specification.

In order to avoid non-deterministic behavior, the modeler should arrange that at most one guard evaluate to true for each incoming token. If it can be ensured that only one guard will evaluate to true, a conforming implementation is not required to evaluate the guards on all outgoing edges once one has been found to evaluate to true.

For use only with DecisionNodes, a predefined guard “else” (represented as an Expression with “else” as its operator and no operands) may be used for at most one outgoing edge. This guard evaluates to true only if the token is not accepted by any other outgoing edge from the DecisionNode.