Decision node incoming flows
vincent...@atosorigin.com
v2.2 (12.3.22, p360):
[1] A decision node has one or two incoming edges and at least one
outgoing edge.
Hence, there is nothing in the specification that prevents the
situations :
- a control node has two incoming control flow and one outgoing
control flow (and no decision input flow)
- a control node has two incoming object flow and one outgoing object
flow (and no decision input flow)
By reading the specification, I have the feeling that in case there is
a second incoming flow it is necessarily the decision input flow.
Moreover, the constraints on the decision input behavior ([5], [6],
[7]) describe all cases but these two.
Do you think that these situations make sense or is there a constraint
missing in the UML specification ?
Thanks in advance for your answers.
H. S. Lahman
Control nodes and decision nodes are different animals. OTOH, the flow
is simply a data flow. Thus a control node consumes (processes) flow
messages or generates them. A decision node simple routes the flow to
the right control node once it has been generated. IOW, control nodes
will always have at least one flow in or out. Where each output flow
goes or where each input flow comes from /may/ be determined by an
intervening decision node. But that sort of flow conditionality is
orthogonal to control node inputs/outputs.
--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer
H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
vincent...@atosorigin.com
> Control nodes and decision nodes are different animals.
generalization of decision node):
- a decision node has two incoming control flow and one outgoing
control flow (and no decision input flow)
flow (and no decision input flow)
> Where each output flow
> goes or where each input flow comes from /may/ be determined by an
> intervening decision node. But that sort of flow conditionality is
> orthogonal to control node inputs/outputs.
Well, actually activity edges coming to a decision node and activity
edges coming to another kind of control node are the same relationship
(inherited by generalization). But that wasn't exactly the point of my
question.
Like I said, the two situations described above are not prevented by
the UML specification. But I do not think they make sense.
From my point of view, the second place available for incoming flows
seems to be reserved for the optional decision input flow.
I think in the two situations above, what a user would want to
represent is a merge node combining the two incoming edges, then a
decision node.
There is a notation ( see Figure 12.76 Decision node notation) which
allows to illustrate the merge and decision node sharing the same
symbol. By using tis notation the diagram looks the same whether we
use a merge node or whether we allow the above situations without
merge node. But from a model point of view, the two situations are
really different and I do not think that the situation with no merge
node should be allowed.
H. S. Lahman
>> Control nodes and decision nodes are different animals.
>>
> Sorry, I was meaning the two situations (though control node is a
> generalization of decision node):
> - a decision node has two incoming control flow and one outgoing
> control flow (and no decision input flow)
>
aka Merge Node.
> - a decision node has two incoming object flow and one outgoing object
> flow (and no decision input flow)
>
aka Merge Node. The nature of the flows does not change the way flow
paths are followed.
Decision nodes and merge nodes are basically the same thing so the same
UML symbol is used. They different from Fork and Join nodes in that they
do involve a split into multiple flows in parallel (Fork) or an implied
wait for both inputs (Join).
Merge nodes just reflect a logical merge of different flow paths into a
single path so there is no conditionality involved; anybody who reaches
the node continues on the same output path no matter how they got to the
node. Decision nodes require a condition to select the correct output
path to follow. But in either case whenever an incoming flow arrives at
a Decision or Merge node, it simply continues on following a single path.
>
>
>> Where each output flow
>> goes or where each input flow comes from /may/ be determined by an
>> intervening decision node. But that sort of flow conditionality is
>> orthogonal to control node inputs/outputs.
>>
Substance abuse alert. I never use UML ADs so my terminology dates from
pre-UML days when process nodes were sometimes called control nodes (a
precursor in some Structured methodologies of Jacobson's notion of
controller objects). So my discussion was based on that view and I
should have checked the OMG docs rather than my memory. (The mind is
always the second thing to go.)
> Well, actually activity edges coming to a decision node and activity
> edges coming to another kind of control node are the same relationship
> (inherited by generalization). But that wasn't exactly the point of my
> question.
>
You are losing me here because I have no idea of what OO generalization
has to do with decision nodes. Are you referring to the <very sloppy
IMO> use of "derived" that appears ubiquitously in the meta model specs
(e.g., Decision nodes are derived from control nodes)?
vincent...@atosorigin.com
> has to do with decision nodes. Are you referring to the <very sloppy
> IMO> use of "derived" that appears ubiquitously in the meta model specs
> (e.g., Decision nodes are derived from control nodes)?
misunderstood due to the differences in the terminologies we use. But
now I see what you meant.
The point that mostly interests me in your answer is :
> aka Merge Node.
Maybe I should precise that I am currently developing a model-based
Activity diagram editor.
As a consequence I do not rely on the visual aspect of the diagram,
but on the UML model elements themselves. My model is based on eclipse
modeling framework (and may be eventually used for automatisation
purpose).
When seeing a diamond with two incoming flows and outgoing flow(s), we
naturally think of a merge node (eventually followed by a decision
node depending on the number of outgoing flows).
But the point is that the specification does not prevent a decision
node being in that configuration. (it must have one or two incoming
edges, including the optional decision input flow which does not exist
in this configuration)
So, when my model contains a decision node, do you think that it is
semantically correct to have two incoming flows for the decision node
model element ?
This situation would of course make the diagram representation
ambiguous, not knowing whether there is a merge node, but the model
elements leave no confusion between a merge and a decision node.
If yes : then we both agree that it has the same semantic as if there
were an extra merge node merging the two incoming flows (though there
is no model element representing a merge node). In such a case, the
specification is not clear about this situation for a decision node.
As I far as I could tell, in such a situation it could have any
positive number of incoming flows and the constraint of less than two
incoming edges is useless.
If no : then there is a constraint missing in the specification and I
shall rise an UML issue. I personally think it is the case, the
constraint having not been as heavily tested as the structure itself
through external usages (I am thinking of the eclipse implementation
of the UML2 norm, which has left constraints over due to a lack of
time).
Best regards,
Vincent.
H. S. Lahman
> The point that mostly interests me in your answer is :
>
>> aka Merge Node.
>>
> Maybe I should precise that I am currently developing a model-based
> Activity diagram editor.
> As a consequence I do not rely on the visual aspect of the diagram,
> but on the UML model elements themselves. My model is based on eclipse
> modeling framework (and may be eventually used for automatisation
> purpose).
>
> When seeing a diamond with two incoming flows and outgoing flow(s), we
> naturally think of a merge node (eventually followed by a decision
> node depending on the number of outgoing flows).
> But the point is that the specification does not prevent a decision
> node being in that configuration. (it must have one or two incoming
> edges, including the optional decision input flow which does not exist
> in this configuration)
>
My version of the v2 spec dates from '03 so I can't speak to any changes
OMG has made since. But in my spec it is pretty clear that the
difference is definitional. If the diamond has one output, it is a merge
node. If there are two or more outputs it is a decision node and a
conditional expression must be provided.
There is some ambiguity because the spec does not explicitly say that a
merge node must have two or more inputs, but that is implicit in the
notion of "merge". Nor does the spec explicitly say that a specifying a
decision condition makes no sense for a merge node, but that is also
implicit in the notion of "decision".
However, I think the real issue here is that OMG was just trying to make
life easier for the modeler by providing a notational mechanism to
eliminate redundancy when one needs both a merge and a decision...
> So, when my model contains a decision node, do you think that it is
> semantically correct to have two incoming flows for the decision node
> model element ?
>
Yes. However, the semantics is different than for Fork/Join. Having two
inputs simply means that two flows have can have the same decision
independently. IOW, there is no wait for simultaneous continuation and
no implied merging of data, etc.. Thus each flow immediately evaluates
the condition to determine which output path should be followed. In a
sense there is a merge of flow paths but they are completely independent
inputs and the notation simply avoids cluttering the model. Without that
convenience one would need something like
in flow 1 in flow 2
| |
| |
<> <> decisions
/ \ / \
/ \ / \
/ \ / \
| <> | merge to same output
| | |
| | |
| out flow A |
| |
| |
+-------<>-------+ merge to same output
|
|
out flow B
when two input flows each lead to the same ouput flow based on the same
condition. IOW, the notation combines decision and merge to make
modeling easier when the paths are logically independent in a temporal
sense. So instead we just have:
in flow 1 in flow 2
\ /
\ /
\ /
\ /
<> decision
/ \
/ \
/ \
out flow A out flow B
There is no ambiguity because the diamond has multiple outputs and a
condition specified. Thus it would be trivial to reify it back to the
first diagram. That's because there is no simultaneity for the inputs;
that would require a Join element that is more narrowly defined and
would not be legal here.
<aside>
I don't see an ambiguity here because the interpretation seems clear
based on number of outputs and from the semantics of "decision" and
"merge" in natural language. However, OMG is not above introducing
ambiguity in the interest of making life easier for the modeler. A
classic example is conditionality and multiplicity being combined on
relationship ends (e.g., 0..*). The notation is elegant but OMG allows a
shorthand of just '*'. Now OMG's definition of the default is
unambiguous, it really means 0..*, but that is contrary to the way OOA/D
works where one goes out of one's way to avoid conditional
relationships. Thus they have made the default the exceptional case in
an OO context, which is counterintuitive. The result is that there are
lots of OOA/D models where the tool thinks the conditionality is
different or worse, the tool transforming the model is not compliant
about the way it implements conditionality (more precisely, it will not
generate the necessary checking for instantiation when navigating
relationships).
</aside>
vincent...@atosorigin.com
> My version of the v2 spec dates from '03 so I can't speak to any changes
> OMG has made since. But in my spec it is pretty clear that the
> difference is definitional. If the diamond has one output, it is a merge
> node. If there are two or more outputs it is a decision node and a
> conditional expression must be provided.
Having a look at the March 2003 v1.5 specification makes me better
understand your point of view.
Mine dates from February 2009 (v2.2) and I had a small look one these
points at the September 2009 2.3 XML version:
Merge node and decision node are now two distinct objects described in
separate chapters.
Decision nodes are explicitely forced to have "at least one outgoing
edge". Which is the reason why I was talking about decision nodes with
1 output to take the simplest case (which has led us to
misunderstanding).
> > So, when my model contains a decision node, do you think that it is
> > semantically correct to have two incoming flows for the decision node
> > model element ?
>
> Yes. However, the semantics is different than for Fork/Join. Having two
> inputs simply means that two flows have can have the same decision
> independently. [...]
OK. That answer and the following explanation was what I was looking
for. (even if I was more expecting its contrary)
Now that decision nodes have extra-attributes (decisionInput and
decisionInputFlow), the constraints applying on these attributes
listed all cases but this one. Which was really confusing me.
Thanks for your answer.
Vincent.
H. S. Lahman
>> My version of the v2 spec dates from '03 so I can't speak to any changes
>> OMG has made since. But in my spec it is pretty clear that the
>> difference is definitional. If the diamond has one output, it is a merge
>> node. If there are two or more outputs it is a decision node and a
>> conditional expression must be provided.
>>
>
> Having a look at the March 2003 v1.5 specification makes me better
> understand your point of view.
>
Mine is the v2.0 '03 spec.
> Mine dates from February 2009 (v2.2) and I had a small look one these
> points at the September 2009 2.3 XML version:
>
> Merge node and decision node are now two distinct objects described in
> separate chapters.
> Decision nodes are explicitely forced to have "at least one outgoing
> edge". Which is the reason why I was talking about decision nodes with
> 1 output to take the simplest case (which has led us to
> misunderstanding).
>
Hmmm. I think OMG has shot themselves in the foot again with that "at
least one..." It seems to me that to have a decision one needs at least
two choices. And if it is an AD, what else would it be deciding than
which flow to take?