TIP/GOTCHA: SysMLv1/UML: Cameo Simulation Toolkit: If you use a «decisionInputFlow» to a DecisionNode you MUST also have a ControlFlow to the DecisionNode; if you don't use an explicit «decisionInputFlow» you don't need the "extra" ControlFlow
UML: Cameo Simulation Toolkit 19SP3: GOTCHA: CreateObjectAction ignores an Artifact as 'classifier' even though Artifact is a Classifier
UML/SysML: Cameo Simulation Toolkit 19SP3: A parent Activity with a DecisionNode that uses a Activity as a decisionInput Behavior terminates immediately after the decisionInput terminates (but OpaqueBehavior works)
If the DecisionNode does not have a decisionInput, then the value contained in the object token on the decisionInputFlow is made available to the guards on each outgoing edge, regardless of whether the primary incoming flow is a ControlFlow or an ObjectFl Source Unified Modeling Language 2.5.1
If a DecisionNode has a decisionInputFlow, then a token must be offered on both the primary incoming edge and the decisionInputFlow before the token from the primary incoming edge is offered to the outgoing edges. Source Unified Modeling Language 2.5.1
UML/SysML: Cameo Simulation Toolkit 19SP3: GOTCHA: Will not evaluate a guard using a token from a decisionInputFlow UNLESS a decisionInput Behaviour is explicitly defined (but Alf does)
Figure 11-12: Continuous system example 3 {EXPLICIT PINS} Gallery Tutorial TRAIL: The SysML-1.6 Hybrid SUV sample and specification diagrams in MagicDraw/Cameo (with annotations) [UNDERGOING UPDATE to SysML1.7] Section Section: SysML-1.6 specification diagrams: 11 Activities Slide kind SysML Activity Diagram
SysML-1.6: An additional ControlFlow is required into the DecisionNode of 'Figure 11-12: Continuous system example 3' and the existing ObjectFlow with Brake Pressure must become a decisionInputFlow
MagicDraw/Cameo: 19SP3: Callout of allocatedFrom on Connector vs ObjectFlow shows «decisionInputFlow» not «objectFlow» keyword
If it has two incoming edges, then one shall be identified as the decisionInputFlow, the other being called the primary incoming edge. If the DecisionNode has only one incoming edge, then it is the primary incoming edge. Source Unified Modeling Language 2.5.1
incoming_control_one_input_parameter If the DecisionNode has a decisionInputFlow and an incoming ControlFlow, then any decisionInput Behavior has one in Parameter ... Source Unified Modeling Language 2.5.1
two_input_parameters If the DecisionNode has a decisionInputFlow and a second incoming ObjectFlow, then any decisionInput has two in Parameters ... Source Unified Modeling Language 2.5.1
decision_input_flow_incoming The decisionInputFlow of a DecisionNode must be an incoming ActivityEdge of the DecisionNode. Source Unified Modeling Language 2.5.1
DecisionNode::edges The ActivityEdges incoming to and outgoing from a DecisionNode, other than the decisionInputFlow (if any), must be either all ObjectFlows or all ControlFlows. Source Unified Modeling Language 2.5.1
zero_input_parameters If the DecisionNode has no decisionInputFlow and an incoming ControlFlow, then any decisionInput Behavior has no in parameters. Source Unified Modeling Language 2.5.1
decisionInputFlow : ObjectFlow [0..1] ... An additional ActivityEdge incoming to the DecisionNode that provides a decision input value for the guards ValueSpecifications on ActivityEdges outgoing from the DecisionNode. Source Unified Modeling Language 2.5.1
