Activity Diagram

Main ideas / lessons conveyed

What an Activity Diagram is

• Activity diagrams are software engineering diagrams that add detail beyond what was previously covered in a context diagram (which provides a “general overview”).
• The video uses an ATM example to show how a high-level service description becomes a detailed, step-by-step process.

Why add detail beyond the context diagram

• The focus is on how the system handles a process internally once you move from a general description to a detailed explanation.
• In the ATM example:
  • Context-level: “Customer requests service (e.g., balance inquiry) → ATM responds.”
  • Activity-level: expands into card insertion → card reading → PIN entry → PIN verification → authorization/next steps → results.

Fundamental properties of activity diagrams

• Visual representation reduces misunderstandings
  • Diagrams prevent ambiguity that can happen when steps are described only as text.
  • Shared conventions (e.g., arrow direction) make it harder for people to disagree about meaning.
• Explicit sequencing
  • Clarifies which steps happen before others (e.g., you cannot verify a PIN before the card is inserted).
• Decision points are clear
  • Highlights where and what decisions occur (e.g., PIN correct vs incorrect; sufficient vs insufficient balance).

Business relevance

• Activity diagrams aren’t only technical—they can represent business processes too (e.g., “move data from here to there”).
• The same logic applies whether the work is done by programmers or business stakeholders.

---

Methodology / “how to build” (instructions-style content)

1) Break down a service into ordered activities

• Start from a service (e.g., ATM cash withdrawal).
• Identify the sequence of tasks from start to finish.
• Ensure each step specifies:
  • What the step is
  • Who performs it (e.g., customer vs system/ATM)

2) Use standard diagram elements (shapes/meanings)

• Start (beginning)
  • Usually a white oval or a square with slanted edges.
• Actions / activities
  • Steps like “insert card,” “read card,” “enter PIN.”
  • Typically drawn as rectangular activity elements (the video notes variants such as rounded edges).
• Decision / branching
  • A diamond shape used to ask/confirm something (often with Yes/No outcomes).
• Merging paths
  • A merge/link point where paths come together (the video associates merge/branch with thick lines in its notes).
• Fork / parallel structure (mentioned)
  • A fork can exist, typically indicated by a thick line.
• End
  • Often matches the start symbol type (oval).
  • Can represent different outcomes (e.g., cash dispensed vs no balance).

3) Define branching outcomes correctly

• Example logic from the ATM scenario:
  • If PIN is correct → proceed to the withdrawal flow.
  • If PIN is wrong → follow an alternate path (the video mentions attempting up to three times, then possibly refusing/withdrawing the card).

4) Assign responsibilities to participants

• Steps should clearly show who does what, e.g.:
  • Customer: inserts card, enters PIN, enters withdrawal amount
  • ATM/System: reads card, asks for PIN, checks PIN, checks balance, dispenses cash, prints invoice

5) Create separate activity diagrams per service

• If there are multiple services (e.g., balance inquiry, cash withdrawal, deposit):
  • Create one activity diagram per service.

---

ATM cash withdrawal example (step-by-step flow described)

Main flow

• Customer inserts card.
• ATM/System reads card information.
• ATM/System asks the customer for the PIN.
• Customer enters the PIN.
• ATM/System checks whether the PIN is correct:
  • If correct → proceed.
  • If incorrect → follow the error/alternate path (including the “try three times” idea).
• ATM/System instructs the customer to enter the withdrawal amount.
• Customer enters amount (example: “2000 riyals”).
• ATM/System checks whether the account balance has enough money:
  • If enough → send amount to the dispenser/cash mechanism, then ATM/System prints/provides the invoice/receipt.
  • If not enough → end with a no balance / insufficient funds outcome.

When “verification” happens (sequence constraint)

The diagram must enforce correct order:

• Read card first
• Request/enter PIN next
• Verify PIN before checking authorization/continuing

---

When to use activity diagrams (explicit guidance)

Use activity diagrams when you need to represent:

• Business processes and procedural steps
• User-case details (e.g., checking balance)
• Algorithms and how they work
• Data workflow (how data moves between places)
• The capabilities of a system and how each is implemented

---

Speakers / sources featured

• Speaker: Unspecified (only “the instructor/lecturer” is present; no name given)
• Sources: None cited (no external references or named authors)