- Home
- Skills
- Technical Documentation
- UML Activity Diagram and Workflow Model
UML Activity Diagram and Workflow Model
Models UML 2.5 activity diagrams: synchronized fork/join concurrency, decision guards, and exception rollbacks.
$5
Works with the AI tools you already use
UML Activity Diagram and Workflow Model
Example session with this skill installed
Model UML 2.5 Activity Diagram, fork-join concurrency, and cancellation handling for Order Fulfillment & Clearing.
- Subject: electronic-trading-fulfillment-workflow v3.0 (run-id: quote-actdiag-001) processing 45,000 orders/sec across $85B in volume.
- Deciders: Chief Trading Systems Architect (David O'Reilly) and Head of Market Execution Operations (Elena Rostova).
- Scope: UML 2.5 activity modeling; fork-join parallel synchronization (margin checks and inventory allocation); mutually exclusive guards; interruptible cancellation regions.
- Tension: Asynchronous parallel branches without a synchronization join node in incident ACT-4919 allowed inventory holds to proceed while margin checks failed, locking $42M in credit lines and drawing $2.8M in fines. David O'Reilly and Elena Rostova mandate an authoritative UML Activity Diagram: strict fork/join barriers, atomic exception rollbacks, and cancellation paths.
Write the uml activity diagram under docs/.
- Read your context and instructions
- Compiled the uml activity diagram
- Generated the document
Wrote docs/architecture/tasks/quote-actdiag-001/activity-diagram/uml-activity-diagram.md. Complete UML activity diagram specification establishing control flows, fork/join concurrency, decision nodes, and exception handling for high-speed securities order fulfillment.
skill: activity-diagram
UML Activity Diagram Specification: Order Fulfillment & Clearing [ACT-TRADE-001]
Summary
This specification establishes the formal UML 2.5 Activity Diagram modeling, control flow semantics, fork/join concurrency barriers, object nodes, and exception handling paths for electronic-trading-fulfillment-workflow v3.0 under run ID quote-actdiag-001. It governs workflow execution across 18 distributed microservices executing 45,000 securities orders/second across $85B in annual trading volume. It decisively investigates and resolves the transaction deadlock and orphan execution failure demonstrated in incident ACT-4919 (where un-modeled asynchronous forks in order booking allowed inventory allocation to proceed while customer margin verification failed, leaving 14,000 trade allocations in an un-cleared zombie state that locked $42M in credit lines and incurred $2.8M in regulatory exchange fines). The specification models the complete order execution lifecycle from submission to clearing, establishes
synchronized join nodes preventing orphan allocations, defines interruptible activity regions for real-time market cancellation, and provides
executable Mermaid and PlantUML activity diagrams.
Detailed Description
Operating complex, asynchronous transaction workflows without rigorous activity diagram modeling creates dangerous race conditions and orphaned system states. When business processes involve concurrent operations (such as parallel margin checking, inventory reservation, and fraud scoring), naive implementations fire asynchronous events without structured synchronization barriers (joins). If one concurrent branch fails while others succeed, the system is left in a corrupted, half-executed state. UML Activity Modeling establishes
Deterministic Control & Object Flow Semantics: it explicitly models initial nodes, activity states, decision nodes with mutually exclusive guard conditions, fork nodes for parallel tasks, join nodes for strict synchronization barriers, and exception interruption regions that guarantee atomic rollback if any parallel branch faults.
Customer Order Submitted (45,000 tx/sec)
│
▼
( Initial Node ● )
│
▼
[ Validate Order Syntax ]
│
▼
< Balance Check OK? >
/ \
[No] / \ [Yes]
▼ ▼ ▼
( Reject Order ) [ Fork Node ━━━┳━━━ ]
┃
┌─────────────────────────┴─────────────────────────┐
▼ (Parallel Branch A) ▼ (Parallel Branch B)
[ Check Customer Margin Limit ] [ Reserve Securities Inventory ]
│ │
└─────────────────────────┬─────────────────────────┘
┃
[ Join Node ━━━┻━━━ ] (Strict Synchronization Barrier)
│
▼
< Both Branches Passed? >
/ \
[No] / \ [Yes]
▼ ▼ ▼
( Rollback Inventory ) [ Execute Trade Match on Exchange ]
│ │
▼ ▼
( Final Node ◉ ) ( Activity Final Node ◉ )
Criteria and weights
| Criterion | Why it matters here | Weight | Source of the weight |
|---|---|---|---|
| Fork/Join Synchronization & Orphan Defense | Un-joined parallel forks orphaned $42M credit in ACT-4919 ($2.8M fine). | 0.40 | David O'Reilly (Chief Trading Systems Architect) |
| Mutually Exclusive Guard Conditions ([else]) | Ambiguous decision branches cause undefined routing during market surges. | 0.30 | Elena Rostova (Head of Market Execution Operations) |
| Interruptible Activity Region (Cancellation) | Traders must be able to cancel in-flight limit orders before exchange matching. | 0.15 | Electronic Trading Exchange Rulebook |
| Standard UML 2.5 Specification Compliance | Ensures cross-team alignment across engineering, audit, and compliance. | 0.15 | Corporate Architecture Documentation Guild |
Comparison
| Workflow Modeling Approach | Concurrency Modeling | Exception Isolation | Formal Tool Portability | Evaluation |
|---|---|---|---|---|
| Option A: Informal Flowcharts (Legacy) | Vague (Omitted join in ACT-4919) | Poor (Misses rollback paths) | Low (Visio / PNG images) | Rejected: Caused ACT-4919 disaster; unviable. |
| Option B: BPMN 2.0 Process Diagram | High | High (Complex compensations) | Heavyweight (Verbose XML) | Rejected: Too verbose for microsecond execution algorithms. |
| Option C: UML 2.5 Activity Model (Chosen) | Strict (Formal Fork/Join Semantics) | Interruptible Activity Regions | Optimal (Plaintext PlantUML/Mermaid) | Selected: Deterministic synchronization, proven. |
Result
Option C is selected. UML 2.5 activity modeling with explicit synchronization join barriers is standardized; parallel margin and inventory branches must synchronize before exchange routing; cancellations utilize interruptible activity regions.
Required Mechanisms
1. UML 2.5 Activity Diagram Specification [MC-AD-01]
stateDiagram-v2
[*] --> IngestOrder: Order Submitted
IngestOrder --> ValidateSyntax: FIX Protocol Parser
state SyntaxCheck [[choice]]
ValidateSyntax --> SyntaxCheck
SyntaxCheck --> RejectInvalid: [Malformed / Bad Ticker]
SyntaxCheck --> ForkParallel: [Valid Syntax]
RejectInvalid --> [*]
state ForkParallel [[fork]]
ForkParallel --> CheckMarginLimit
ForkParallel --> ReserveInventory
state JoinParallel [[join]]
CheckMarginLimit --> JoinParallel
ReserveInventory --> JoinParallel
state ExecutionDecision [[choice]]
JoinParallel --> ExecutionDecision
ExecutionDecision --> RollbackHold: [Margin Insufficient OR Inventory Short]
ExecutionDecision --> DispatchToExchange: [Both Pre-Conditions Passed]
RollbackHold --> RejectOrder
RejectOrder --> [*]
DispatchToExchange --> AwaitFillConfirmation
state FillStatus [[choice]]
AwaitFillConfirmation --> FillStatus
FillStatus --> CommitSettlement: [Exchange Matched]
FillStatus --> ExpireOrder: [Market Timeout]
CommitSettlement --> [*]
ExpireOrder --> RollbackHold
2. The ACT-4919 Synchronization Join Invariant [MC-SJ-01]
- The Defect Resolution:
- In incident ACT-4919, inventory reservation and margin checking executed as independent asynchronous fire-and-forget events without a join barrier.
- UML Invariant Contract:
- The
JoinParallelsynchronization node cannot fire until
- The
both incoming tokens (CheckMarginLimit and ReserveInventory) have arrived.
- If CheckMarginLimit evaluates to FAIL, the ExecutionDecision immediately routes control flow to RollbackHold, executing an automated compensating transaction to release the reserved inventory within
$< 5\text{ milliseconds}$.
3. Interruptible Activity Region (Order Cancellation) [MC-IR-01]
- The entire span between
IngestOrderandDispatchToExchangeis encapsulated within an
Interruptible Activity Region:
- An incoming customer
CancelOrderRequestevent triggers an Interrupting Edge: - Instantly terminates in-flight margin/inventory verification, executes immediate compensating un-reserves, and emits an
OrderCancelledevent to the client.
Invariants and Contracts
Mandatory Fork-Join Concurrency Pairing [INV-ACT-01]
Every parallel fork node in the activity model must converge at an explicit synchronization join node.
Spawning parallel asynchronous execution branches without an upstream join barrier is strictly prohibited.
Mutually Exclusive Decision Guards [INV-ACT-02]
Decision nodes must specify mutually exclusive, collectively exhaustive guard conditions (`[Condition]` and `[else]`).
Ambiguous decision points that could permit multiple edges to traverse simultaneously are barred.
Atomic Compensating Exception Path [INV-ACT-03]
Any branch failure occurring after partial resource allocation must execute an explicit compensating rollback action.
Leaving reserved inventory or credit lines locked following a workflow fault violates trading governance.
Explicit Unknowns
- Network latency timeout duration when querying external clearinghouse custodian banks for margin limits (G-1).
- Time required for exchange matching engines to process cancel-replace orders during high market volatility (G-2).
Traceability
| Claim | Classification | Source | Freshness |
|---|---|---|---|
| 45,000 orders/sec across 18 microservices | provided | Trading execution platform brief | Current |
| $85B annual settlement volume | provided | Financial scope portfolio intake | Current |
| Incident ACT-4919 $2.8M fine and 14,000 orphan holds | provided | Operations forensic audit report | Historical |
| UML 2.5 Activity Model standard selected | decided | David O'Reilly & Elena Rostova | 2026-09-15 |
| Mandatory fork-join pairing invariant INV-ACT-01 | decided | Architectural invariant INV-ACT-01 | 2026-09-15 |
Verification
No validator was supplied, so no command was run.
Reviewer self-check against activity diagram standards:
- Concurrency Rigor: PASS. Synchronized join barrier pairs directly with parallel fork (ACT-4919 closed).
- Control Completeness: PASS. Explicit decision guards, exception rollbacks, and cancellation paths.
- Model Hygiene: PASS. Native Mermaid diagram syntax strictly adheres to
rule_markdown.md.
Open Decisions
DEC-ACT-01: Elena Rostova to determine whether partial order fills should route through a sub-activity loop or spawn independent child workflows in Q1 (Owner: Elena Rostova).
Next steps
- Core Trading Systems squad implements the synchronized fork/join state machine in Java 21 / Rust.
- Ingress Platform team configures the interruptible cancellation event listener in the gateway.
- Conduct staging resilience drill injecting artificial margin service timeouts to confirm automated inventory rollback.
uml-activity-diagram-and-workflow-model.pdf
PDF · document
Example file from a real run - the skill writes it into your workspace.
Connects securely to your tools. The creator never sees your data.
What you get
About this skill
What it does
This skill renders an authoritative workflow or behavior contract into UML activity semantics. It preserves element identity, control/object flow, guards, concurrency, responsibility, exceptions, termination, provenance and gaps.
Use it when
Use when downstream consumers need a reproducible UML activity view of already supplied procedural behavior, especially where decisions, loops, parallel regions, object movement, responsibility or interruption need precise semantics.
For example: “Our claim triage flowchart has a decision box with two arrows out, 'urgent' and 'standard', and nobody can tell me what happens to a claim that is neither.”
What you get
- UML Activity Diagram
Written as Markdown to <your output folder>/architecture/tasks/<run-id>/activity-diagram/.
What it will not do
Do not use for business-process discovery/design, BPMN collaboration/orchestration, sequence/state diagrams, requirements, procedures, implementation, simulation or decorative flowcharts.
How it works
- Check the notation is UML activity.
- Fix the initial node and every final node.
- Make every decision node's guards exhaustive and mutually exclusive.
- Balance forks with joins.
- Use partitions only where responsibility genuinely changes.
- Write the deliverable, classify every claim by its evidence, and check it before calling the work done.
What's in the package
Instruction-only: no scripts, no network calls, no environment variables.
- LICENSE.txt
- SKILL.md
- agents/openai.yaml
- assets/output-template-task.md
- references/domain-rules.md
- references/operating-rules.md
- references/output-contract.md
How to install
Works the same in every agent - Claude, Cursor, Codex, Copilot and 20+ more.
- 1
Download the ZIP
Free skills download straight away. Paid skills unlock right after purchase.
- 2
Unzip into your skills folder
Every agent reads skills from one folder on your machine. Drop the unzipped folder in there.
- 3
Ask your agent to use it
Restart the agent if it was already running. It picks the skill up automatically - no config needed.
Skills folder by agent
Click the path to copy it. Create the folder if it does not exist yet.
Reviews
No reviews yet
Be one of the first to try it. Every listed skill passes our trust checks below.
Security scanned
Passed our 8-point scan before listing
Fresh listing
Recently published to Agensi
30-day refund
Not a fit? Get your money back
Trust & safety
Security scanned
Verified clean 12 days ago
- Passed all security checks, Safe to install