Activity diagram - conditional node

[fbvb]

I need to use the conditional node activity diagram. However, I did not find an example of how to do a simple if-else with this component.


[original message]

[qwerty]

Either use the Decision element or simply use a guard with the transitions.

q.
[original message]

[fbvb]

In this example (http://www.inf.ufsc.br/~fabiane.benitti/example.png) there are 2 if, at first I used the conditional node. In the second, as I do? Because for each "test" there is only one "body".
[original message]

[qwerty]

That's nonsense. It mixes fragments for sequence diagrams in an activity diagram. You "can" do that, but as said it is nonsense. If you leave it completely away you see the decision and the guards. That's "IF" enough.

q.
[original message]

[M@localhost Simon M]

WARNING - This is outside of the scope of my personal usage. The following is based on a reasonable ability to read and understand the UML specification and knowledge of EA.

qwerty - This is at least mostly a valid activity diagram. I'll go into the mostly below.

In your example, the conditional node may as well not exist. (The decision is what is driving it, not the conditional node)

The UML specification clearly defines a conditional node as a collection of ordered clauses. (test+body) So an if-else needs to be one clause with a condition, and a second (successorClause) where the condition is always true.

In fact UML states that:
Quote:

An “else” Clause is a Clause that is a successor to all other clauses in the ConditionalNode and whose test section always results in true. The body section for such a Clause will be enabled if and only if no other body section in the ConditionalNode is enabled. This ensures that at least one body will always be executed for the ConditionalNode.

Alterations to your model that I would make for (my interpretation of) conformance) are:

• Move the target for the control flow from your message directly to the conditional node.
  
• Move the control flow from your decision to a new initial node inside the body (removing the guard)
  
• Change the decision node into an action placing the value of NOT(actual position = next position) onto an output pin.
  
• In the properties of the conditional node, set that output pin as the "decider" of the first clause
  
• In the properties of the conditional node, create a second clause
  
• Add an action out an output pin with the value true for the second test.
  
• I assume you then want to specify an else body in the second body section.
  

It's also possible to have a control flow directly from the outside into a body. My interpretation of that would be that the test (and any tests on predecessorClauses) would then act as a guard on that flow.
[original message]

[qwerty]

Well, UML 2.5 describes Fragments within Interactions (communication/sequence). Activity diagrams already have sufficient syntax to show algorithmic constructs like if and loop. So a fragment in an activity diagram is simply nonsense.

q.
[original message]

[fbvb]

Thank you Simon.

I was able to make some changes you proposed. But the item 3 does not appear the option to select int the "decider". And the last two items I did not understand the proposal - the second clause is for the "else" the conditional node or whether it is to create the second test (NOT encerrada / encerrada).

I've never used this structure (conditional node) and I am trying to understand how it works.

I made available the .eap file http://inf.ufsc.br/~fabiane.benitti/activityDiagram.eap

thanks
[original message]

[M@localhost Simon M]

qwerty - Nonsense because you disagree with the creators of UML that it should be part of the Activity specification, or nonsense because you don't understand it?

fbvb - Not sure what's wrong with selecting the decider. Possibly a bug. Given that there's only one action pin in that block, it can't really be anything else. If there were multiples I would probably use color or thick lines to highlight the relevant one.

Add an action out an output pin with the value true for the second test.

Literally put the value "true". Given you've used the convention of using the expression as the name for the action pin, I would name the decider in the second test as true. This makes it an "else" rather than an "else if".

I assume you then want to specify an else body in the second body section.

You said you wanted an if-else block. So filling the body with a different set of actions would be equivalent to writing code in that block.
[original message]

[qwerty]

Simon, it's nonsense because its redundant (and to a very low fraction because it's not with the specs). The "if" is already expressed with the Decision node and the guards.

q.
[original message]

[M@localhost Simon M]

6C6A786F69641D0 wrote:

Simon, it's nonsense because its redundant (and to a very low fraction because it's not with the specs). The "if" is already expressed with the Decision node and the guards.

Yes, I said that it was redundant on the initial diagram. My personal opinion is that in the simple case it's also much harder to read than a decision node with guards. But I can also see that once you have more than a couple of clauses (conditions) using this notation would be easier to read.

Maybe it would be more helpful to read UML 2.5 section 16.11 before categorizing the whole thing as nonsense.
[original message]

[qwerty]

You are right. This is a new concept in 2.5. Though it seems like bundling several actions in a so-called StructuredActivity looks like a good concept, I don't think that it is one indeed. Discussing that is likely off-topic. So the only thing I can say: it's compliant but I would not use it. I'm out here.

q.
[original message]

[M@localhost Simon M]

67617364626F160 wrote:

You are right. This is a new concept in 2.5.

Not that it matters, but it was pretty much the same in UML 2.0. (Replacing ConditionalAction in UML 1.5)
[original message]

[qwerty]

Which tells us that UML still has elements which are conceptually wrong or at least very strange. What is the reason that EA does not have the StructuralActivity metatype?

q.
[original message]

[M@localhost Simon M]

It does. Drop 'Structured Activity' from the toolbox.
[original message]

[qwerty]

Which proofs: you don't see things you don't want to see :-[
Pretty sure it hasn't been there in former version, though. Somewhere before 9.3 ...

q.
[original message]

[minastaros2]

I agree that a simple decision node is much clearer to read than a conditional node box, because to have 'test' and 'body' in two stacked compartments, visibly interrupting the control flow (connectors!), lets one stumble.

However I can imagine that for expressing a larger (maybe >4 cases) switch-case construct, which UML lacked so far, a kind of multi-conditional node (as I have seen somewhere) might be cleaner than a long chain of decision nodes (is 1? no, else - is 2? no, else - is 3?...).

And for a long time, I have been looking for a better loop construct which expresses the intention better than a loop made of decision nodes (see some early and still erroneous attempts here: http://stackoverflow.com/questions/15792687/loop-in-uml-activity-diagram-using-a-region).
Now I have just modelled an iterating-over-all-elements loop with an expansion region/nodes, which is pretty clean and beautiful.

Conclusion: imho, in some cases, these structured nodes can help, sometimes simple things are better.

Sorry, that was somewhat off-topic now... :-?
[original message]

[qwerty]

No, it was not. Thanks for sharing your opinion.

q.
[original message]