A sequence diagram for the city's Webex ChatOps bot shows only the happy-path 200 from the Webex API. Design review asks how the diagram should also cover a 401 or timeout without turning into application source code. What belongs on the diagram?
Select an answer to reveal the explanation.
Short Explanation
Happy path alone is half a story. An alt or opt fragment on the diagram is the stage direction for 'what if the API says no or goes silent'—still design, not source code.
Full Explanation
Failure paths belong on sequence diagrams as interaction fragments, not as pasted source. An alt or opt fragment that places the 401 or timeout path beside the happy-path 200 keeps the Webex ChatOps design review at the design level: same lifelines, alternate outcomes, still readable. That covers “API says unauthorized” or “API goes silent” without becoming application code.
Pasting a full Python try/except into a note without a fragment frame dumps implementation detail and does not structure alternate flows the way UML/sequence fragments do. A second network topology page redrawing every switch is the wrong artifact class for API failure semantics. Removing the Webex API lifeline so failures cannot appear hides the dependency instead of documenting how the bot should behave when Webex fails.
Exam caveat: opt is for an optional path; alt is for mutually exclusive alternatives—either is acceptable for “success vs 401/timeout,” but empty happy-path-only diagrams fail design review. Operational check: ensure the fragment names the condition (401, timeout), shows the bot’s follow-up message or error handling at the design level, and still lists the Webex API as a participant. Place the success 200 and the 401/timeout alternatives inside the same fragment region so reviewers see they share the preceding request. For the city’s Webex bot, the failure arm should show a user-visible ChatOps error or retry decision at the design level without embedding stack traces.