Loop Fragment vs. Decision Node: Choosing the Right UML Approach for Retry Logic without Duplicate Writes

Goal

Model retry logic in an activity diagram while ensuring that write operations are not duplicated across attempts.

Constraint

The diagram must represent a retry mechanism that updates a counter or condition atomically with the write action, preserving idempotency.

Unresolved Decision

The UML 2.5 specification does not prescribe a standard pattern for retry semantics or write deduplication. Two common patterns are:

• Loop Fragment with Guard – encloses the write activity and repeats based on a counter guard.
• Decision Node with Guard – routes back to the write activity only when a retry condition is met, potentially avoiding duplicate writes.

Questions

• Does a loop fragment with a counter guard guarantee that the write action is invoked only once per retry attempt?
• Can a decision node with an explicit guard prevent re‑entry to the write action while still allowing multiple retry attempts?
• Is there a UML construct that explicitly supports idempotent retry semantics, or must modelers rely on external state management?