Source: NIST ( Conrad Bock)
Decision/MergeNodes are (indirectly) typed by KerML:Decision/MergePerformance (via specialization of Actions::Action::decisions/merges), which KerML Clause 18.104.22.168 (Control Performances Overview) requires:
Successions going out of Steps typed by DecisionPerformance or its specializations must:
• be included in a Feature of its featuringBehavior that unions (see 22.214.171.124) all the outgoing Successions, and is bound to the outgoingHBLink of the Step (see 126.96.36.199 on feature chaining).
Successions coming into Steps typed by MergePerformance or its specializations must:
• subset a Feature of its featuringBehavior that unions all the incoming Successions, and is bound to the incomingHBLink of the Step.
while constraints in 188.8.131.52 (DecisionNode) and 184.108.40.206 (MergeNode) say
All outgoing Successions from a DecisionNode must subset the inherited outgoingHBLink feature of the DecisionNode.
All incoming Successions to a MergeNode must subset the inherited incomingHBLink feature of the MergeNode.
with similar text in 220.127.116.11 (Control Nodes) under Decision / Merge Nodes. These constraints allow outgoing/incomingHBLink to have values that are not identified by outgoing/incoming successions when none of the successions is traversed. The KerML pattern above introduces a feature unioning the successions and binds it to a chain through decision/merge to outgoing/incomingHBLink, ensuring the HB links are identified by the successions. See Annex A.3.7 (Timing for behaviors, Decisions and merges) for an example, at the end of the model to be executed (first code listing), under "Decision and merge timing constraints".
Reported: SysML 2.0b1 — Wed, 16 Aug 2023 17:21 GMT
Updated: Tue, 12 Sep 2023 15:51 GMT