6.3 Decision, Merge, Fork & Join Execution

6.3 Decision, Merge, Fork & Join Execution

Quick Reference: SysML separates conditional branching from concurrent execution using distinct control node geometries. Decision (1-to-N) and Merge (N-to-1) nodes use hollow diamonds to route tokens along mutually exclusive alternative paths without synchronization. Fork (1-to-N) and Join (N-to-1) nodes use thick black bars to initiate and synchronize concurrent parallel threads. Confusing Merge with Join is the primary cause of activity model deadlocks.

---

Branching vs. Concurrency: The Architectural Divide

A fundamental requirement in systems behavioral modeling is distinguishing between two different types of flow divergence and convergence:

1. Alternative Branching (Choice): The system evaluates dynamic conditions and selects exactly one path out of several mutually exclusive options. The other paths are not executed. This is modeled using Decision Nodes and recombined using Merge Nodes.
2. Concurrent Execution (Parallelism): The system initiates all paths simultaneously or in arbitrary order. Every path executes independently. This is modeled using Fork Nodes and synchronized using Join Nodes.

Mixing up the symbols or semantics of these two paradigms leads to non-functional system models and fatal simulation failures.

---

Decision Nodes: Conditional Selection

A Decision Node routes an incoming control or object token to one of several alternative outgoing edges based on evaluated guard expressions.

Geometry and Notation

• Shape: A hollow diamond (rhombus) symbol (◇).
• Connectivity: Exactly one incoming edge (or one primary edge and one decision input flow) and two or more outgoing edges.
• Guard Conditions: Outgoing edges of a decision node normally carry a guard condition in square brackets, [guardExpression]. An edge with no guard is treated as always true.

Guard Evaluation and Firing Rules

• Dynamic Evaluation: When a token arrives at the decision node, the guard conditions on all outgoing edges are evaluated.
• Mutual Exclusivity: Guards should be modeled as mutually exclusive so that only one guard evaluates to true for any given system state.
• Token Routing: The token is offered only to the single outgoing edge whose guard evaluates to true. A decision node never duplicates tokens; exactly one token enters, and that same single token exits down the selected path.
• The Predefined [else] Guard: A modeler can designate at most one outgoing edge with the reserved guard [else]. The [else] path is selected if and only if all other guards evaluate to false. This prevents token stagnation (where a token is trapped because no guard evaluates to true).
• Decision Input Flow (Advanced): An optional secondary edge marked with stereotype «decisionInputFlow» can feed data from an object node directly into the decision diamond to supply the parameter values evaluated by the guards without passing through the branch itself.

---

Merge Nodes: Recombining Alternative Paths

A Merge Node brings multiple alternative incoming paths back together into a single outgoing flow.

Geometry and Notation

• Shape: A hollow diamond (rhombus) symbol (◇), visually identical in shape to a Decision Node.
• Connectivity: Two or more incoming edges and exactly one outgoing edge.
• Absence of Guards: Outgoing edges on a merge node do not require guard conditions.

The Zero-Synchronization Rule

The most critical semantic rule regarding Merge Nodes is:

A Merge Node NEVER synchronizes flows.

• When a token arrives on any incoming edge, the merge node immediately forwards that token to its single outgoing edge.
• It does not wait for tokens on other incoming edges.
• If three separate tokens arrive across different incoming edges over time, the merge node passes each token through individually, producing three separate outgoing tokens.
• Merge nodes are the required targets for loopback paths when modeling cyclic iterations in SysML activities.

---

Fork Nodes: Creating Concurrent Threads

A Fork Node splits a single incoming flow into multiple concurrent, parallel execution paths.

Geometry and Notation

• Shape: A thick solid black line segment (horizontal or vertical bar).
• Connectivity: Exactly one incoming edge and two or more outgoing edges.
• No Guards Permitted: Outgoing edges from a fork node cannot have guard conditions; all paths execute unconditionally.

Token Replication Semantics

• When a single token arrives at a Fork Node, the node creates a duplicate copy of the token for each outgoing edge.
• Each outgoing edge immediately offers a token to its downstream target.
• Downstream actions across all outgoing branches execute concurrently (in parallel or in arbitrary interleaved sequence).

---

Join Nodes: Synchronizing Concurrent Threads

A Join Node synchronizes multiple concurrent flows back into a single unified flow.

Geometry and Notation

• Shape: A thick solid black line segment (horizontal or vertical bar), visually identical in shape to a Fork Node.
• Connectivity: Two or more incoming edges and exactly one outgoing edge.

Synchronization Semantics (Logical AND)

• By default, a Join Node performs a strict logical AND synchronization.
• A Join Node waits until a token is present and offered on every single incoming edge.
• Arriving tokens are held in wait states at the join boundary.
• Only when all incoming edges hold an offered token does the Join Node fire: it consumes one token from each incoming edge, merges them, and emits a single unified token onto its outgoing edge.

Join Specification (joinSpec)

SysML allows modelers to override the default "wait for all" behavior by attaching a constraint note labeled joinSpec. For example, joinSpec = {flowA or (flowB and flowC)} allows the join node to fire when specific subset conditions are fulfilled.

---

Comparison Matrix: Decision vs. Merge vs. Fork vs. Join

---

The Two Critical Architectural Traps on the Exam

Trap 1: The "Deadlock by Join" (Mismatched Decision and Join)

Consider a modeler who routes a flow through a Decision Node with guards [temp > 100] and [temp <= 100]. Because the guards are mutually exclusive, a token will travel down Path A or Path B, but never both.

If the modeler attempts to recombine these two paths using a Join Node (thick bar):

• The token traverses Path A and arrives at the Join Node.
• The Join Node holds the token and waits for a token to arrive on Path B.
• Because Path B was never activated by the Decision node, no token will ever arrive on Path B.
• Result: The system enters a permanent, fatal deadlock. The Join Node hangs forever and downstream actions never execute.
• Correction: Conditional paths originating from a Decision node must always recombine using a Merge Node (diamond), never a Join Node!

Trap 2: The "Unintended Multi-Execution" (Mismatched Fork and Merge)

Conversely, consider a flow split by a Fork Node (thick bar) into two concurrent paths: Record Telemetry and Calculate Trajectory. Both paths execute in parallel and produce a token.

If the modeler attempts to recombine them using a Merge Node (diamond):

• Path 1 finishes and delivers a token to the Merge Node. The Merge Node immediately emits it downstream, causing the downstream action Transmit Report to execute.
• A few milliseconds later, Path 2 finishes and delivers its token to the Merge Node. Because Merge does not synchronize, it immediately emits this second token downstream as well.
• Result: Downstream actions execute twice instead of once, potentially triggering redundant commands or corrupting data.
• Correction: Concurrent paths originating from a Fork node must always recombine using a Join Node (bar) to synchronize back into a single token.

---

Exam Pitfalls & Misconceptions