The Pulse of Process: Actions, Streams, and Data Currents

by

Think of activity diagrams as the choreography of your system—they show how everything dances together. At the heart of this movement are three key elements: actions (the dance steps), control flows (the sequence), and object flows (what’s being passed between steps). Get these right, and your diagram sings. Get them wrong, and you’ve got a tangled mess.

Let’s break it down with fresh examples and practical insights.

1. Actions: The “Doers” of Your System

Actions are where the work happens. Each one is a discrete task, like a single move in a dance routine.

Real-World Action Types You’ll Actually Use

  • “Make the Call” Actions
    • Example: In a food delivery app, “Notify Driver” triggers an alert to the nearest courier.
    • Why it matters: This isn’t just a step—it’s a system event with consequences (like a driver rejecting the order).
  • “Wait for It…” Actions
    • Example: A smart thermostat “Waits for Temperature Threshold” before kicking on the AC.
    • Watch out: These often get overlooked, leaving teams wondering why a process “hangs.”
  • “Decide and Route” Actions
    • Example: An e-commerce return system “Checks Refund Eligibility”—then branches to “Approve Refund” or “Flag for Review.”

Pro Tip: Name actions like you’re giving orders to a robot:

  • ❌ “Customer Data Handling” (Too vague)
  • ✅ “Validate Credit Card” (Clear and testable)

2. Control Flows: The Conductor’s Baton

Control flows answer one question: “What happens next?”

Where Teams Go Wrong

  • The Linear Trap
    Assuming everything happens step-by-step. Reality: Most systems have parallel flows.
    • Example: When you book a flight, the system:
      • Charges your card (💰 flow)
      • Reserves your seat (🪑 flow)
        These happen at the same time—model them with fork/join nodes.
  • The “Everything Depends on Everything” Mess
    Drawing control flows that look like a subway map.
    • Fix: Use decision diamonds sparingly. If you need more than 3 branches, your action’s probably too complex.

Hot Take: Control flows should read like a recipe.

  • Bad: A single arrow from “Prep Ingredients” to “Serve Dinner.”
  • Good: Explicit steps for “Chop Veggies” → “Sauté” → “Plate” with decision points (“If too salty, add cream”).

3. Object Flows: The Hidden Paper Trail

While control flows show when things happen, object flows show what’s moving between steps.

Critical Details Most Diagrams Miss

  • State Changes
    • Example: In a document approval system:
      • Draft Proposal (object) → “Review” (action) → Approved Proposal (modified object)
      • Show this: Add notes like “Version 1.0 → 1.1” on the flow arrow.
  • Real-World Objects
    • Bad: Modeling “Data” as a generic blob.
    • Good: Specificity like “PDF Contract” or “Biometric Scan”—these hint at interface requirements.

Case Study: Vaccine Distribution

  • Object flow clarity saves lives:
    • Vial (Unopened) → “Thaw” → Vial (Ready for Draw) → “Administer Dose”
    • Miss the state change? Nurses might draw from frozen vials.

The Dynamic Duo: How Control + Object Flows Work Together

The Coffee Shop Test

Imagine modeling a barista’s workflow:

  1. Control Flow:
    • Take Order → Grind Beans → Brew Coffee
  2. Object Flow:
    • Customer’s Order (Text) → “Grind Beans” → Ground Coffee (20g) → “Brew”

Why both matter:

  • Control flow ensures espresso isn’t brewed before grinding.
  • Object flow guarantees the right coffee amount is used.

Red Flag: If your diagram has actions floating without inputs/outputs, you’re missing critical dependencies.

Pro Tips for Diagrams That Don’t Lie

  1. Color-Code for Clarity
    • Blue arrows for control flows
    • Green arrows for object flows
      (Yes, this breaks UML purity—but your team will thank you.)
  2. Add “Kill Switches”
    Show error flows explicitly:
    • “Process Payment” → (if failed) → “Lock Account”
    • Don’t hide these in notes.
  3. Benchmark Against Reality
    Print your diagram and walk through a real user’s journey. Does it:
    • Match how the pharmacist actually fills prescriptions?
    • Reflect the courier’s actual package scan points?
      If not, redraw.

When to Break the Rules

Sometimes, you need to bend UML for clarity:

  • Merge simple object/control flows when the distinction doesn’t matter (e.g., “Submit Form” → “Confirmation Email”).
  • Use icons (like a 📄 for documents) if your team isn’t UML-fluent.

Remember: Diagrams are communication tools—not religious artifacts.

Final Thought: Your Diagram Should “Play” Like a Storyboard

A great activity diagram lets stakeholders visualize the system in motion. Try this test:

  1. Pick an actor (e.g., “Emergency Responder”).
  2. Trace their path through the diagram while narrating:
    • “First, they get the alert (object), then assess severity (action), which decides if they dispatch police or EMTs (control flow)…”

If it tells a coherent story, you’ve nailed it. If not—time to simplify.

Leave a Comment