Exercises — UML — use case, class, sequence, activity, state machine, component diagrams

(a) Use Case diagram — it lists actors (roles outside the system) and their goals as ovals. No implementation detail. (b) Class diagram — the three-compartment box (name / attributes / operations) plus relationship lines. (c) State Machine diagram — one object's life as a set of states and event-labelled transitions. Anchor: look at the tree in the figure. (a) and (c) sit under Behavioural; (b) sits under Structural.

(i) ▷ = Inheritance / Generalization ("is-a"). Dog ▷— Animal. (ii) ◆ = Composition ("owns-a", the part dies with the whole). House ◆— Room. (iii) ◇ = Aggregation ("has-a", part can live independently). Library ◇— Book. (iv) ⇢ = Dependency ("uses temporarily", e.g. a method parameter type).

False. The dashed vertical line is the lifeline (it shows the object exists through time). The activation bar is the thin rectangle laid over the lifeline showing the moments the object is actively running a method. An object can exist (lifeline present) but be idle (no bar).

• Checkout --<<include>>--> Validate Cart. The <<include>> arrow points from the base to the included case, because the base always depends on it. (incluDe → Depends always.)
• Apply Coupon --<<extend>>--> Checkout. The <<extend>> arrow points from the extension to the base, because the optional extra reaches into the base. (eXtend → eXtra/optional.) Notice the directions are opposite — that is the whole distinction.

$\text{Order}⧫\text{—}\underset{1}{}\underset{\mathrm{1..}\ast }{}\text{OrderLine}$ In words: Order "1" ◆—— "1..*" OrderLine.

• Filled diamond ◆ on the Order side → composition, because deleting the Order destroys its lines (lifecycle test: must the part die? → yes).
• 1..* means "one or more" (at least one line). 1 on the Order side means each line has exactly one owning order.

• The call is a synchronous message: a solid line with a filled (solid) arrowhead — the caller blocks until it returns.
• The reply is a return message: a dashed line with an open arrowhead (⇠) carrying the result, e.g. ok. (If the ATM did not wait, it would be an asynchronous message — solid line, open arrowhead.)

It should be aggregation ◇, not composition ◆. Apply the lifecycle test: "If I delete the University, must every Student cease to exist?" No — students transfer, graduate elsewhere, keep existing as people. The part outlives the whole → aggregation (hollow diamond). Composition is reserved for parts with no independent meaning once the whole is gone (e.g. Invoice ◆—— InvoiceLine).

A decision (◇) chooses exactly one guarded branch — mutually exclusive. But here we need both tasks to run, so a decision is semantically wrong. Correct: use a fork (━) to launch both actions in parallel, then a join (━) to wait until both complete before Close Order. $\text{Payment Received}\to \boxed{\text{fork}}\to (\text{Send Email}\Vert \text{Update Inventory})\to \boxed{\text{join}}\to \text{Close Order}$ See the figure below: fork/join (parallel) vs decision/merge (choose one).

No — a state machine is also wrong here. The right tool is a sequence diagram. Reason: the requirement is object A talks to object B, message by message, in time order. A sequence diagram puts objects across the X-axis and time down the Y-axis — exactly this need. An activity diagram hides objects and shows only the flow of work, so it cannot show "who talked to whom". (Compare: use activity when you care about the workflow, not the collaborators.)

• Initial ● → Draft.
• Draft —submit→ Under Review
• Under Review —approve→ Published
• Under Review —reject→ Draft
• Under Review —comment→ Under Review ← self-transition (fires, records a comment, state unchanged)
• Published —archive→ Archived
• Archived → Final ◉ (nothing leaves Archived).

The comment self-transition is the key modelling choice: an event that does something (records the comment as an /action) yet does not move the object to a new state.

• Actors: Member, Librarian.
• Associations: Member —— Borrow Book, Member —— Return Book, Librarian —— Return Book.
• Include (always): Borrow Book --<<include>>--> Authenticate Member (base depends on it every time).
• Extend (optional): Send Reminder --<<extend>>--> Borrow Book (only when due-soon condition holds; arrow points into the base from the extension).
• Authenticate Member is factored out via <<include>> because it is shared and never skipped — the textbook reason to include.

(1) Use case: Withdraw Cash --<<include>>--> Authenticate — authentication is mandatory, factored out.

(2) Sequence (single scenario):

• Customer → ATM : insertCard()
• ATM → Bank : validate(pin) (synchronous — solid filled arrowhead, ATM waits)
• Bank ⇠ ATM : ok (dashed return)
• alt [balance ≥ amount] → ATM → Bank : debit(amount) ; ATM → Customer : dispenseCash()
• else [balance < amount] → ATM → Customer : showError()

(3) State machine:

• ● → Idle
• Idle —insertCard / readCard→ Authenticating
• Authenticating —validate [ok]→ Dispensing
• Authenticating —validate [not ok] / ejectCard→ Idle
• Dispensing —cashTaken→ Idle

Consistency check: the validate/authenticate step is present in all three — as an <<include>> (use case), as a synchronous message (sequence), and as the Idle → Authenticating → Dispensing transitions (state machine). The alt [balance ≥ amount] in the sequence corresponds to the two guarded outcomes; the [not ok] transition matches the else error path. Different viewpoints, one system.

Count the arrows:

1. ● → Idle (initial)
2. Idle → Authenticating
3. Authenticating → Dispensing [ok]
4. Authenticating → Idle [not ok]
5. Dispensing → Idle

Total transitions = 5. Guarded transitions = 2 (arrows 3 and 4 carry [ok] / [not ok]).

Which family is a Class diagram in? ::: Structural (static shape). Direction of the <<include>> arrow? ::: From the base use case to the included one. Lifecycle test that separates composition from aggregation? ::: "If I delete the whole, must the part die?" Yes → composition ◆; No → aggregation ◇. Decision ◇ vs Fork ━? ::: Decision picks exactly one guarded branch; fork activates all branches in parallel. What is an activation bar (not the lifeline)? ::: The rectangle showing when an object is actively running a method.