Sequence Diagrams and Data Flow Design
A self-study textbook covering essential theory, comparative examples, guided practice, quality review, and a capstone exercise. Central question: Which objects communicate behind the screen, and in what order?
Learning Goals and Study Routine
Which objects communicate behind the screen, and in what order? You complete today’s lesson when you can answer this question in your own words, produce the required artifact, and review its quality.
Decompose a requirement into Actor, Boundary, Control, and Entity.
Distinguish synchronous messages, asynchronous events, and returns.
Use alt, opt, loop, and par fragments.
Explain race conditions created by concurrent requests.
Create an executable Mermaid sequence diagram.
Check consistency across requirements, APIs, and data models.
Recommended self-study routine
- Explain why a problem occurs before memorizing its terminology.
- Describe the difference between good and poor examples using observable criteria.
- Attempt the capstone before opening the model answer.
- Mark missing conditions in a second color and revise your artifact.
Table of Contents
- Study Guide and Learning GoalsPage 02
- Chapter 1. Core Theory and Design PrinciplesPage 04
- Chapter 2. Guided Design PracticePage 05
- Chapter 3. Case Review and Quality CheckPage 06
- Chapter 4. Capstone and Model AnswerPage 07
- Glossary and Final ChecklistPage 08
- Self-study reference and guided practicePages 09–11
Submit the capstone artifact, score at least 80/100 on the self-review, and write your own answers to the four concept questions.
Core Theory: Sequence Diagrams and Data Flow Design
Each technical term exists to solve a recurring design problem. Study when and why the concept is needed, not merely its definition.
| Core concept | Working definition |
|---|---|
| Lifeline | The time axis of a user, interface, service, database, or external participant. |
| Message | A request or response exchanged between participants. |
| Activation | The interval in which a participant is performing work. |
| Combined Fragment | A notation for alternatives, options, repetition, or parallel work. |
| Boundary | A UI or API at the edge between a user or external system and the application. |
| Control / Entity | The components that coordinate business flow and retain persistent data. |
Poor and Effective Approaches
Avoid
Represent every internal responsibility as one generic “System” participant.
Prefer
Separate the reservation UI, reservation service, payment gateway, and database so ownership and failure points are visible.
[Trigger] → [Participants] → [Sync/Async Messages] → [State Change] → [Response or Compensation]
A Six-Step Design Workflow
Define the problem
Mark the user goal and initiating condition in the requirement.
Extract the structure
Extract the UI, services, external APIs, and data stores as participants.
Design the core flow
Place the happy-path requests and responses in chronological order.
Add failure conditions
Add failures, timeouts, and duplicates with alt fragments.
Connect policies
Connect locks, versions, or idempotency policies to shared resources.
Verify and trace
Trace requirement IDs to API and table names in the diagram.
Worked Example
Questions for reading the example
- Are the input and initiating condition explicit?
- Are success and failure outcomes observable?
- Are duplication, authorization, concurrency, and dependency failure covered as needed?
- Can the result be traced back to a requirement?
Concept Check and Quality Review
- When should a call be synchronous rather than event-driven?
- How do alt and opt fragments differ?
- Why should timeouts appear in the diagram?
- How can retransmitted requests avoid duplicate work?
Answer each in two or three sentences and add one example that supports your explanation.
Self-Assessment · 100 points
| Area | Standard | Points |
|---|---|---|
| Accuracy | Concepts and technical choices match the facts and requirements. | 25 |
| Completeness | Normal flow, boundaries, failures, and recovery are covered. | 25 |
| Consistency | Terms, IDs, states, and interfaces agree across artifacts. | 20 |
| Verifiability | Observable outcomes and completion criteria are present. | 20 |
| Reasoning | The choice and its tradeoffs can be explained clearly. | 10 |
Do not only correct the result. Record which question you failed to ask so your next design process prevents the same omission.
Capstone Exercise and Model Answer
Design a sequence in which two users attempt to reserve the same seat. Include the case where payment succeeds but the database write fails.
- List assumptions and unresolved decisions first.
- Produce the main design as a table, diagram, or code block.
- Include the normal flow and at least three failures or boundaries.
- Score it with the rubric and compare before and after revision.
Open the model answer
The booking service must allow only one request to proceed by locking the seat row or validating a version. If payment succeeds but booking persistence fails, invoke an authorization void or refund as compensation and record an operational alert.
How to use the answer
The model is not the only valid design. If yours differs, explain the requirement, cost, complexity, or risk that justifies your choice.
Glossary and Final Checklist
| Term | Plain-English meaning |
|---|---|
| Actor | A user or external system pursuing a goal. |
| Lifeline | A participant’s time axis. |
| alt | A conditional fragment that chooses one flow. |
| par | A fragment containing flows that may run concurrently. |
| Race Condition | A result that depends on execution order. |
| Compensation | A later action that reverses the effect of an earlier completed step. |
Eight checks before submission
- Can you answer today’s central question in your own words?
- Are inputs, conditions, and results explicit?
- Did you include failures and recovery, not only the happy path?
- Did you review concurrency, duplicate requests, and permissions?
- Did you account for dependency failure and timeouts?
- Can you explain the disadvantages and alternatives to your choice?
- Are terminology and states consistent across artifacts?
- Is there an observable or testable completion standard?
Which objects communicate behind the screen, and in what order? Answer it now using evidence from the artifact you created.
Key Terms in Context
Learn each term as a decision tool. Read across each row: definition, reason to use it, and the failure it prevents.
| Term | Plain definition | Why it matters | Example or caution |
|---|---|---|---|
| Synchronous call | The caller waits for a response before continuing. | Use it when an immediate result is required. | A slow dependency makes the whole request slow. |
| Asynchronous event | The sender continues and receives the outcome through an event. | It decouples notifications and follow-up work. | Define ordering, retries, and duplicate consumption. |
| Idempotency | Repeating the same request produces the same final effect as one request. | It prevents duplicate bookings and charges. | Store a request key and return the recorded result. |
| Race condition | The result changes depending on the order of concurrent work. | It matters for scarce inventory and seats. | Combine checking and updating in one protected operation. |
| Timeout | A call fails when no response arrives within a defined limit. | It prevents indefinite waits and resource exhaustion. | Pair it with retry limits and a user-facing outcome. |
| Compensation | A later action reverses the effect of an earlier successful step. | It repairs partial failure across services. | Void a payment when saving the booking fails. |
Two users reserve the final seat at the same time, and the database write fails once after payment approval.
Guided Practice and Troubleshooting
Practice scenario
Two users reserve the final seat at the same time, and the database write fails once after payment approval.
Complete in order
- List the actor, UI, booking service, payment service, and database as lifelines.
- Draw the happy path first and label every message with its input and return value.
- Add concurrent requests, payment rejection, and save failure as separate alt branches.
- Assign ownership of idempotency, seat locking, and payment compensation.
Save one artifact, three assumptions, and at least three failure cases. A classmate should be able to reproduce your reasoning without asking what you meant.
If the result is wrong, diagnose it
| Observed symptom | Likely cause | Next action |
|---|---|---|
| Seat sold twice | Availability check and update are separate | Row lock or conditional update |
| Payment approved twice | A retry is treated as a new request | Idempotency key and stored result |
| UI waits forever | No dependency timeout | Timeout, retry limit, and failure response |
Check Your Understanding
Retrieval check — answer before opening
How do alt and opt differ?
alt chooses one of multiple guarded paths; opt runs one optional path only when its guard is true.
Why compensate after a save failure?
It resolves the mismatch where money moved but no booking exists.
When is the diagram complete?
Normal, failure, and recovery paths have clear owners and map to implementation elements.
Explain the day's main decision, one failure mode, and one verification method without reading the page. If you cannot connect all three, return to the row or diagnostic case you missed.