UML 2.2 RTF Avatar
  1. OMG Issue

UML22 — Flowing data into decision input behaviors

  • Key: UML22-1120
  • Legacy Issue Number: 10815
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Document: Unified Modeling Language: Superstructure, Version 2.1.1 (formal/2007-02-03)
    Sections: 12.3.22, DecisionNode

    (This issue surfaced during work on the Semantics of a Foundational Subset for Executable UML Models submission.)

    Background

    There is no direct way to flow a supporting value into the decision input behavior of a decision node.

    Suppose one wants to set up a decision node with a decision input behavior that, say, takes an object as an input and tests whether an attribute of that object has a certain value. Further, suppose that value is given by an input parameter of the enclosing activity. The value of the parameter is provided via an activity parameter node, but there is no direct way to connect an object flow from the activity parameter node to the test for the decision node.

    Currently, a decision input behavior can only have a single input parameter, which will get the object flowing into the decision node that is to be tested. And, since it is a separate behavior from the enclosing activity, a flow from the enclosing activity can't be connected into the decision behavior. Of course, it would be possible to save the parameter value into an attribute of the enclosing activity, and then read that attribute in the decision behavior – but this seems awfully round about!

    Note that there is no problem using a Conditional Node since, in that case, the test is not a separate behavior, and data can flow from the enclosing action into the test. It is just with (the supposedly simpler) Decision Node that there is a problem.

    Proposal

    Decision nodes may optionally have one additional incoming edge identified as the "decision input". If there is no decision input behavior, tokens offered on the decision input edge are made available to the guards on outgoing edges to determine whether the offer on the other incoming edge is passed along that edge. If there is a decision input behavior and a decision input edge, the token offered on the decision input edge is passed to the behavior (as the only argument if the regular incoming edge is control flow, as the second argument if it is object flow). Decision nodes with the additional decision input edge will offer tokens to outgoing edges only when one token is offered on each incoming edge.

  • Reported: UML 2.1 — Fri, 9 Mar 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Adopt as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT