Reading a scenario into a UML diagram
Eleven diagrams from the course, each taught the same way: what it is for, every symbol, how to pull the elements out of an exam scenario, a worked example from your own activities and slides, the solved diagram, and a pre-submit checklist.
Everything here comes from your Ch.1–Ch.9 slides, Activities 3–5, and the graded Major 1. Worked solutions for Activities 3 and 4 are derived step by step from the activity text because no answer keys for them were provided. Any symbol or diagram that is not in your material carries a dashed named only label or a dashed "Outside course material" box.
How to read the colour marks in scenarios
class, actor, participant, lane, componentattributeoperation, use case, action, messagerelationshipstructural or exam clue
Callout types: Common mistake, Exam tip, From the graded Major 1 (thick red border), Mnemonic (double border), Outside course material (dashed).
Class diagram
1What this diagram is for
Your slides define it in one line: class diagrams show the classes of the system, their inter-relationships, and the operations and attributes of the classes. It is the blueprint of what exists in the software and how those things are connected. It says nothing about the order in which things happen.
It belongs to the logical view of the 4+1 model, as a static diagram (with the object diagram). Its stakeholders are end-users, analysts and designers. In Chapter 5 it is also the main tool of component design: the internal structure of each architectural component is modeled "through one or more class diagrams".
classes, attributes, operations/methods, relationships, structure of the system, the system stores / keeps records of, draw the UML for this design pattern. Any question built around a list of things with properties (a listing contains an address, image, price…) is a class diagram question.
2Every symbol and notation
Class box
- Looks like
- A rectangle split into three compartments: name, attributes, operations.
- Means
- One kind of thing in the system (Account, Bank, ATM Transaction).
- Use it when
- For every noun that has its own data and its own behavior.
- Common mistake
- Drawing a class with no attributes and no operations. If it holds nothing and does nothing, it is probably an attribute of another class.
Attributes and operations
- Looks like
-
Middle compartment lists data (
+balance). Bottom compartment lists behavior with brackets (+debit()). - Means
- Attributes are what the object knows; operations are what it does.
- Use it when
- Adjectives/properties become attributes. Verbs the class is responsible for become operations.
- Common mistake
-
Putting a verb in the attribute box, or forgetting the
()on operations.
+debit(), +credit(),
+withdrawal()
Visibility symbols
- Looks like
-
A single character before an attribute or operation:
+,-,#. - Means
-
+public,-private,#protected. Private attributes are how encapsulation (Ch.1) appears on a diagram. - Use it when
-
-for data you want hidden,+for operations other classes call. - Common mistake
-
Mixing them up or leaving them out entirely. Your ATM slide
puts
+on everything; that is accepted, but-on attributes shows encapsulation.
+ shown on every ATM slide class;
private/protected listed in Ch.5 L2 (abstract class
attributes)
Association (with name and direction)
- Looks like
- A solid line between two classes, optionally with an open arrowhead and a name like Maintains.
- Means
- The two classes are structurally connected. The arrow shows directionality: the action originates at the tail (ATM Transaction Modifies Account).
- Use it when
- Whenever one class needs to know about another over time (Bank maintains ATMs).
- Common mistake
- Thinking the arrow is required. Your slide: a bidirectional association can have two arrows or no arrows.
Multiplicity
- Looks like
-
Numbers at each end of an association:
1,1..*,0..*,0..1. - Means
-
How many objects on that end can be linked to one object on
the other end.
1..*= one to many,1= exactly one. - Use it when
- On every association in an exam answer. Read it as: one Agent manages 0..* records.
- Common mistake
- Putting the number on the wrong end. The number next to Listing describes how many Listings, not how many Agents.
Generalization (inheritance)
- Looks like
- Solid line with a hollow triangle pointing at the superclass.
- Means
- "is-a": the subclass is a specialized form of the superclass (Current Account is an Account).
- Use it when
- When the scenario lists shared data plus extra data for special kinds (houses vs condos).
- Common mistake
- Pointing the triangle at the subclass. It always points from subclass to superclass.
Abstract class and method
- Looks like
- Class name in italics; abstract operations also in italics.
- Means
- A class that cannot be instantiated; it gives a template and default behavior to subclasses.
- Use it when
- When the general class should never exist on its own (there is no plain "User", only Agents and Managers).
- Common mistake
- Writing the word abstract but not italicizing, or italicizing concrete methods.
Interface
- Looks like
-
A box with
«interface»above the name; operations only, no attributes. - Means
-
A contract of methods with no implementation. Java keyword
implements. - Use it when
-
When unrelated classes must offer the same operations (every
Observer has
update()). - Common mistake
- Adding attributes or method bodies to an interface.
Realization
- Looks like
- Dashed line with a hollow triangle pointing at the interface.
- Means
- The class implements the interface's operations.
- Use it when
-
Class → «interface». Shown as
«realize»in the Composite structure. - Common mistake
- Using a solid line (that is generalization) for an interface.
Aggregation
- Looks like
- Solid line with a hollow diamond at the whole.
- Means
- Whole–part where the part can exist on its own.
- Use it when
- "has a", "consists of" where parts outlive the whole.
- Common mistake
- Drawing the diamond at the part end. The diamond always sits on the whole.
Composition
- Looks like
- Solid line with a filled diamond at the whole.
- Means
- Strong whole–part: the part cannot exist without the whole and is destroyed with it.
- Use it when
- "is made of", "contains" where the parts have no life outside the whole.
- Common mistake
- Using composition whenever you see "has". Ask: if the whole is deleted, do the parts die too?
Dependency
- Looks like
-
Dashed line with an open arrowhead, sometimes labelled like
«create». - Means
- A weaker "uses" relationship: one class temporarily uses another (as a parameter or to create it).
- Use it when
- Client → interface it calls; a factory → the product it creates.
- Common mistake
- Using dependency where the link is permanent. A permanent link is an association.
«create»)
Ch.5 L2 slide 13 draws Cat extends Animal (an
abstract class) with a dashed triangle and
calls it Realization. In standard UML, extending a class (even
an abstract one) is generalization, solid line;
dashed realization is reserved for implements an
«interface». If an exam asks, the safe split is:
extends → solid △, implements → dashed △. If your
instructor marks by the slide, mention both.
3How to extract a class diagram from a written scenario
- Candidate classes from nouns. Underline every important noun or entity: people, things, records, places. At this point you keep them all.
- Class or attribute? A noun is a class if it has its own data and its own behavior or life. It is an attribute if it is a single value describing something else (address, price, date). Test: can I list two or more properties of it? If not, attribute.
- Attributes. Look for "contains", "has", "includes", "records", "stores", "consists of" followed by values. Look for adjectives and numbers.
- Operations from responsibilities. Verbs attached to a class ("an agent creates a listing", "managers approve") become operations on the class that performs or owns the action.
- Relationships. Verbs that connect two classes ("associates listings with agents", "manages") become associations. Name them with the verb.
- Multiplicity. Find counting words: "a single", "a number of", "usually one", "sometimes", "at a time". Write both ends.
- Inheritance, aggregation, composition. "In case of houses… For condos…" means shared attributes in a superclass and specific ones in subclasses. "Part of / made of" suggests ◇ or ◆.
- Review against the scenario. Re-read each sentence and point to where it lives in your diagram. Any sentence you cannot point to is a missing element.
4Instructor-style worked example: Activity 3, real estate system
The company's system associates listings with agent records. These include name, address, and employment start date. A single agent manages a number of listings at a time. While a listing is usually managed by a single agent, sometimes it happens that a listing is transferred from one agent to another. It is recorded when an agent starts and ends to manage a listing.
… any user must first have their credentials verified. An agent can create a listing and then retrieve it… Some agents can update listings… A listing update becomes complete only after a manager approves it. Managers can get listing reports… remove a listing to an archive file or… to a trash can (deletion).
Step 1–2: candidate nouns, then class or attribute
Candidates: company, house, condo, listing, property address, image, year built, area, price, floors, lot, basement, storage, balcony, agent, name, address, employment start date, user, credentials, manager, report, archive file, trash can.
Kept as classes: Listing,
House, Condo, Agent,
Manager, User. Each has several
properties or clear responsibilities.
Became attributes: address, image, year built, area, price (of Listing); floors, lot size, basement (of House); storage, balcony (of Condo); name, address, start date (of Agent); username/password as the credentials (of User).
Rejected: company (the whole system; not an
object inside it), report (an output of an operation,
no stored data given),
archive file / trash can (destinations with no
attributes; modelled as a status value of Listing
plus the operations archiveListing() and
deleteListing()).
Step 3–4: attributes and operations
Attributes come straight from "contains" and "include" sentences. Operations come from what each role can do: Agent creates, retrieves, updates; Manager approves, gets reports, archives, deletes; every User has credentials verified.
Operations go on the class that
performs the responsibility in this scenario.
Putting createListing() on Agent reflects "an
agent can create a listing".
Step 5–6: relationships and multiplicity (the hidden class)
"A single agent manages a number of listings" gives Agent 1 — 0..* Listing. But the next two sentences break that simple line: a listing can be transferred, and the system must record when an agent starts and ends. Start and end dates belong to neither Agent nor Listing; they belong to the pairing.
So we promote the pairing to its own class,
ManagementRecord (startDate, endDate): Agent 1 —
0..* ManagementRecord 0..* — 1 Listing. Over time one listing
collects several records (one per agent who managed it), which
is exactly how the transfer history is kept.
Rejected alternative: a direct Agent—Listing line with
1 at the agent end. It cannot store two agents
over time or the start/end dates, so it fails the last
sentence of the paragraph.
Manager approves updates: Manager 0..1 — 0..* Listing (a listing may not have a pending approval yet).
Step 7: inheritance
"In case of houses… For condos…" is the textbook
generalization clue: shared data stays in
Listing; House and Condo inherit it and add their
distinguishing attributes.
Agents and Managers are both users who must have credentials
verified, so User becomes an
abstract superclass (italic name): there is no plain
user in the scenario, only agents and managers.
Step 8: review against the scenario
Houses and condos → subclasses. Listing data → Listing attributes. Agent records → Agent. One agent many listings, transfers, start/end → ManagementRecord. Credentials → User. Create/retrieve/update → Agent ops. Approve, reports, archive, delete → Manager ops. Every sentence is placed.
Note: "some agents can update listings" is a permission rule. Class diagrams cannot show "some"; mention it in a note or leave it to the use case diagram.
5Final solved diagram
6Exam checklist
What do I look for in the scenario?
- Nouns with several properties → classes
- "contains / includes" → attributes
- Verbs a role performs → operations
- "a single… a number of" → multiplicity
- "In case of X… For Y…" → inheritance
- Data about a pairing (dates, history) → a separate class
Symbols I must remember
- 3-compartment box
- + - # visibility
- Solid line + name, optional arrow
- △ solid = generalization, △ dashed = realization
- ◇ aggregation, ◆ composition (on the whole)
- Dashed → dependency
- Italic = abstract, «interface»
Most common mistakes
- Triangle pointing to the subclass
- Diamond on the part instead of the whole
- Classes with no content
- Missing multiplicity on one end
- Modelling an attribute (price, date) as a class
60-second check before submitting
- Every class has a name and at least attributes or ops
- Every association has 2 multiplicities
- Re-read each sentence: where is it on my diagram?
- Arrowheads: triangles only for inheritance/realization
Object diagram
The Ch.2 L3 slides list the object diagram only as a static
diagram of the logical view ("class/object diagram") and in the
4+1 summary table. No object diagram is drawn or exercised. What
is in your slides is the
object naming used on the sequence and
collaboration diagrams: underlined C : customer,
Accnt : Account,
CKA : Checking Accont. The notation below is built
on that; attribute-value slots are standard UML, not from your
slides.
1What this diagram is for
An object diagram is a snapshot of the class diagram at one moment: real instances with real values, connected by links. It is used to check that a class diagram can represent an actual situation (one customer, their account, their checking account).
Think of it when a question says "a specific…", "at a given moment", "instances", or gives concrete names and values.
2Every symbol and notation
Object (instance)
- Looks like
-
A box with
objectName : ClassNameunderlined; attributes shown asname = value. - Means
- One specific object of a class.
- Use it when
- When the question gives concrete people or items.
- Common mistake
- Forgetting the underline or the colon, which makes it look like a class.
Link
- Looks like
- Plain solid line between two objects, no multiplicity.
- Means
- An instance of an association from the class diagram.
- Use it when
- Between objects whose classes are associated.
- Common mistake
- Adding multiplicities (a link connects exactly two objects, so there is nothing to count).
3How to build it from a scenario
- Start from the class diagram. Every object must be an instance of a class you already have.
- Pick the moment. The scenario usually describes one situation ("customer Sara owns one checking account").
-
Name each instance as
name : Class, underlined. - Fill attribute values only where the scenario gives them.
- Draw links only where the class diagram has an association.
4Worked example built from the ATM class diagram
Using the ATM class diagram (customer Owns Account, Debit Card Provides Access to Account, Checking Account as the specialized account) and the object names already on your ATM sequence slide, one moment of the system looks like this. Attribute values are illustrative.
5Final diagram
6Exam checklist
What do I look for in the scenario?
- Concrete names or values
- "at a moment", "an instance of"
Symbols I must remember
- Underlined
name : Class attr = value- Plain links
Most common mistakes
- Drawing classes instead of objects
- Multiplicities on links
60-second check before submitting
- Every object's class exists
- Every link matches an association
Use case diagram
1What this diagram is for
Slide definition: a behavioral diagram used to capture, specify, and visualize required system behavior. It shows who uses the system (actors) and what goals they achieve with it (use cases). It does not show order or internal steps.
It is the diagram of the scenario / user view, the "+1" that ties the other four views together, discovers architectural elements, and validates the design against functional and non-functional requirements.
actors, users of the system, functionality, what each user can do, system services, user view / scenario view. Sentences shaped "[role] can [verb] [thing]" are use cases.
2Every symbol and notation
Actor
- Looks like
-
Stick figure with a role name underneath. Your ATM slide
also marks it
«actor». - Means
- A role outside the system that interacts with it (Bank Client, Agent, Manager). A role, not a specific person.
- Use it when
- For every kind of user or external system that starts or takes part in a use case.
- Common mistake
- Drawing the system itself, or a database inside the system, as an actor.
Use case
- Looks like
- An ellipse with a verb phrase inside.
- Means
- One goal the actor achieves with the system (Withdrawal Amount, Deposit Amount).
- Use it when
- For each "can + verb" that delivers value to the actor.
- Common mistake
- Writing steps ("enter PIN", "press OK") as separate use cases; those are steps inside one use case.
System boundary
- Looks like
- A rectangle around the use cases, labelled with the system name.
- Means
- What is inside the software versus outside (actors).
- Use it when
- Always, in an exam answer.
- Common mistake
- Putting actors inside the box.
Association (actor – use case)
- Looks like
- Plain solid line, no arrowhead.
- Means
- This actor participates in that use case.
- Use it when
- Between every actor and each use case they use.
- Common mistake
- Adding arrows or labels that belong to «uses»/«extends».
«uses» (include)
- Looks like
-
Dashed arrow from the base use case to a reused one,
labelled
«uses». - Means
-
The base use case always performs the other one as part of
itself. Your slide uses the older word
«uses»; current UML calls it«include». - Use it when
- When a behavior is mandatory in one or many use cases (every job requires credential verification).
- Common mistake
- Pointing the arrow at the base. It points to the included use case.
«extends» (extend)
- Looks like
-
Dashed arrow from the optional use case to the base use
case, labelled
«extends». - Means
- Optional or special-case behavior that is added to a base use case only sometimes.
- Use it when
- "sometimes", "optionally", "in case of error" (Invalid pin «extends» Approval process).
- Common mistake
- Reversing the direction. «extends» points to the base, the opposite of «uses».
The ATM use case slide was produced in an older tool and draws «uses» / «extends» with hollow triangle heads. Standard UML draws both as dashed lines with open arrowheads, which is what this guide uses. Keep the stereotype words exactly as your slide spells them.
3How to extract a use case diagram from a scenario
- Find the actors. Every role that uses the system: "agents", "managers", "customer", "bank client". Also external systems if they start interactions.
- Find the goals. Each "[role] can [verb] [object]" becomes a use case named Verb + Object.
- Merge steps into goals. "Enter card, enter PIN, enter amount" are steps of Withdraw Cash, not three use cases.
- Connect actors to use cases with plain lines.
-
Find mandatory shared behavior ("must first", "only
after", "always") →
«uses». -
Find optional behavior ("sometimes", "in case of", "if
invalid") →
«extends». - Draw the boundary and name the system.
4Worked example: Activity 3, real estate use cases
Reasoning, clue by clue
- Actors: Agent, Manager. Listings and archives are data, not actors.
- Agent use cases: Create Listing, Retrieve Listing, Update Listing.
- Manager use cases: Get Listing Report, Archive Listing, Delete Listing, Approve Listing Update.
- "must first… any job" is mandatory for every use case → every use case «uses» Verify Credentials. Alternative accepted by many markers: one Log In use case linked to both actors; the «uses» version is closer to the wording "to do any job".
- "complete only after a manager approves" is mandatory for an update → Update Listing «uses» Approve Listing Update, and Manager is associated with Approve Listing Update.
- Archive vs trash: two different outcomes with different triggers ("ceases to market" → deletion), so two use cases. Rejected: a single "Remove Listing" that hides the difference.
- "Some agents": a permission detail. A use case diagram cannot say "some"; you can note it in text.
5Final solved diagram
6Exam checklist
What do I look for in the scenario?
- Roles → actors
- "can + verb" → use cases
- "must first / only after" → «uses»
- "sometimes / in case of" → «extends»
Symbols I must remember
- Stick figure
- Ellipse
- Boundary box
- Plain line
- Dashed «uses» → included
- Dashed «extends» → base
Most common mistakes
- Steps as use cases
- Actors inside the boundary
- «uses»/«extends» arrows reversed
- Arrowheads on actor lines
60-second check before submitting
- Every actor connects to at least one use case
- Every use case name is Verb + Object
- Arrow direction: «uses» → reused one; «extends» → base
Activity diagram
1What this diagram is for
Slide definition: the activity diagram helps to describe the flow the system, and explore operations and processes. It is a flowchart of actions: what happens first, what is decided, what can run in parallel, and who is responsible for each action (swimlanes).
It supports the process view, which covers dynamic, run-time behavior, concurrency and synchronization, with developers and integrators as stakeholders.
workflow, process steps, flow of the system, if… otherwise…, then, at the same time / in parallel, process view. Activity 4 asks for it right after the use case scenario, because an activity diagram is the picture of that scenario.
2Every symbol and notation
Initial node
- Looks like
- Small filled black circle.
- Means
- Where the flow starts. One per diagram.
- Use it when
- At the top of the first lane that acts.
- Common mistake
- Drawing it as a hollow circle, or having two starts.
Action / activity
- Looks like
- Rounded rectangle with a verb phrase.
- Means
- One step of work (Validate ATM Card, Enter Pin).
- Use it when
- For each thing the system or actor does.
- Common mistake
- Writing a condition inside an action ("is balance ok?"). Conditions belong on a decision.
Decision + guards
- Looks like
- Diamond with one incoming flow and several outgoing flows, each labelled with a guard in square brackets.
- Means
- Choose exactly one path depending on a condition.
- Use it when
- "if", "otherwise", "valid/invalid".
- Common mistake
- Leaving guards unlabelled, or guards that overlap (both could be true).
Merge
- Looks like
- Same diamond, but several incoming flows and one outgoing.
- Means
- Alternative paths come back together.
- Use it when
- After branches that end in the same next step.
- Common mistake
- Using a join bar to merge alternative paths (a join waits for all of them and would block forever).
Fork
- Looks like
- Thick black bar, one flow in, several out.
- Means
- Start actions that run in parallel.
- Use it when
- "at the same time", "while", "in parallel".
- Common mistake
- Using a fork for an either/or choice. That is a decision.
Join
- Looks like
- Thick black bar, several flows in, one out.
- Means
- Wait until all parallel actions finish.
- Use it when
- After every fork.
- Common mistake
- Forgetting the join, which leaves parallel paths dangling.
Activity final node
- Looks like
- Bullseye: circle with a filled dot.
- Means
- The flow ends. You may have more than one.
- Use it when
- At the end of every path, including error paths.
- Common mistake
- Leaving a branch without an end.
Swimlane (partition)
- Looks like
- Vertical columns with a header naming a participant.
- Means
- Who is responsible for each action.
- Use it when
- When the scenario names several participants (Customer, ATM Machine, Bank).
- Common mistake
- Placing an action in the wrong lane (the Bank, not the ATM, authorizes the PIN).
Control flow
- Looks like
- Solid arrow between nodes.
- Means
- Order: the next action starts when the previous one finishes.
- Use it when
- Between every pair of consecutive nodes.
- Common mistake
- Missing arrowheads, so the reader cannot tell direction.
3How to extract an activity diagram from a scenario
- Write the use case scenario first. Activity 4 asks for it before the diagram. Number the main steps and list alternatives.
- Choose lanes from the participants named: the actor and the system parts (Customer, ATM System, Database).
- Turn each step into an action named with a verb, and place it in the lane of whoever performs it.
- Mark every "if / otherwise / in case" as a decision with complementary guards.
- Mark "then" and ordinal words as sequential flow. Only "at the same time" justifies a fork.
- End every path. Error branches end too, or merge first and then end.
- Trace it: follow each guard with your finger and check it matches a sentence.
4Worked example: Activity 4, Withdraw cash
First deliverable: the use case scenario (Activity 4 asks for this)
Use case: Withdraw Cash. Primary actor: Customer. Supporting: Bank database, cash dispenser.
Main success scenario: 1. The ATM displays the menu of withdrawal amounts with a cancel option. 2. The customer selects the amount. 3. The ATM checks the amount against the available balance. 4. The ATM tests whether sufficient cash is in the dispenser. 5. The ATM interacts with the database to debit the amount from the account. 6. The ATM dispenses cash. 7. The ATM instructs the user to take the cash.
Alternatives: 2a. Customer cancels → menu program exits. 3a. Amount greater than balance → error message, use case ends. 4a. Insufficient cash in dispenser → error message, use case ends.
Reasoning from clue to symbol
- Lanes: Customer, ATM System, Bank Database, because the text names the ATM system, the customer and "the database". The cash dispenser is part of the ATM here, so it stays in the ATM lane.
- "first displays menu" → initial node then Display withdrawal menu.
-
"option to cancel… if the user cancels" → decision
with
[cancel]and[amount selected]. The cancel path ends with Exit menu program and a final node. -
"If greater than the balance… Otherwise" → decision
[amount > balance]/[amount ≤ balance]. The balance lives in the database, so the balance check action is in the Database lane. - "If there is insufficient cash" → second decision. Both error paths display the same message, so they merge before one Display error message action. This reuses one action and is exactly why merges exist.
- "debit… Then it dispenses" → sequential. Rejected: the fork/join from the ATM slide. That slide debits and gives money in parallel, but Activity 4 says then, so a fork would contradict the scenario.
5Final solved diagram
6Exam checklist
What do I look for in the scenario?
- Participants → lanes
- Each verb step → action
- if / otherwise → decision + guards
- "then" → sequence, "meanwhile" → fork
Symbols I must remember
- ● start, ◉ end
- Rounded action
- ◇ decision / merge
- ▬ fork / join
- Lanes
- [guards]
Most common mistakes
- Fork used for if/else
- Guards missing or overlapping
- Dead-end branches
- Action in the wrong lane
60-second check before submitting
- One start, every path ends
- Every decision has ≥ 2 labelled exits
- Every fork has a join
- Read the flow back as the scenario
Sequence diagram
1What this diagram is for
Slide definition: a sequence diagram is used to model interactions between design units together with the messages exchanges and the time-order of the messages. Your extra note contrasts it with the class diagram: the class diagram is structure, the sequence diagram is behavior over time. It shows the order of interactions, explains behavior step by step, and clarifies who does what in a use case.
It is a dynamic diagram of the logical view. In Chapter 4 it is also how the instructor shows an architectural pattern running (Blackboard speech recognition, MVC real estate).
messages, over time, order of interactions, who calls whom, request / response, draw the sequence diagram for [pattern] / [use case].
2Every symbol and notation
Lifeline
- Looks like
-
Box at the top with
name : Class(underlined in the ATM slide) and a dashed vertical line below. - Means
- One participant existing over time. Time runs downward.
- Use it when
- For each object or component that sends or receives a message.
- Common mistake
- Drawing a class name alone with no colon, or lifelines for things that never exchange a message.
C : customer, A : ATM
Actor lifeline
- Looks like
- Stick figure on top of a lifeline.
- Means
- An external user starting the interaction.
- Use it when
- When a human or external role sends the first message.
- Common mistake
- Treating the actor as part of the system.
Message (call)
- Looks like
-
Solid line with a filled arrowhead, labelled
n : operation(). - Means
- One participant asks another to do something. The number gives the order.
- Use it when
- Every request or command.
- Common mistake
- Messages that go upward in time, or missing numbers when the question expects them.
4 : verify pin()Return / reply
- Looks like
- Dashed line with an open arrowhead, going back to the caller.
- Means
- The answer to an earlier call. The Blackboard solution labels it "feedback".
- Use it when
- When the caller needs a result (Pin OK, balance).
- Common mistake
- Drawing returns solid, or returning to someone who never called.
Activation bar
- Looks like
- Thin rectangle on a lifeline.
- Means
- The period when that participant is busy handling a message.
- Use it when
- From receiving a call until its return.
- Common mistake
- Leaving the caller inactive while it waits for a reply it needs.
Self message
- Looks like
- Arrow that leaves and returns to the same lifeline.
- Means
- The object calls one of its own operations.
- Use it when
- Internal processing (processSpeech, compare values).
- Common mistake
- Sending it to another lifeline by accident.
8 : processSpeech()
Create message
- Looks like
-
Message labelled
new …()pointing at a new participant's box. - Means
- Object creation during the interaction.
- Use it when
- When the scenario says an object is created.
- Common mistake
- Drawing the created object at the very top as if it existed from the start.
aModel := new Model()
Note
- Looks like
- Rectangle with a folded corner, dashed line to the thing it explains.
- Means
- A free-text comment.
- Use it when
- Explaining a condition or state change that has no message.
- Common mistake
- Using a note instead of a real message.
Combined fragments for loops and conditions (alt,
opt, loop frames) and asynchronous
open-arrow calls do not appear in your material. For if/else
logic, the course pairs the sequence diagram with an
activity diagram or a use case scenario that
lists the alternatives. If you choose to use an
alt frame, say it is standard UML.
3How to extract a sequence diagram from a scenario
- Lifelines. The actor who starts it, then every object/component the text says the system "interacts with" (ATM, database, cash dispenser). Left to right in order of first appearance.
- Order. Number the sentences of the main success path. Each sentence gives one or two messages.
-
Messages. For each verb that crosses between
participants, draw a call from the one who acts to the one who
is asked. Name it as an operation:
debit(amount). - Returns. Wherever a result is needed to decide the next step (balance, cash available), add a dashed return.
- Activations. Bar from each received call until it returns. The controlling object (ATM) stays active for the whole scenario.
- Alternatives. Draw the main success scenario; handle error paths in the activity diagram or with a note, since your slides do not cover alt frames.
4Worked example: Activity 4, Withdraw cash
Reasoning from clue to message
- Lifelines: Customer (actor), ATM, Account database ("interacts with the database"), Cash dispenser ("tests whether sufficient cash is available in the cash dispenser"). Rejected: a separate "Menu" or "Error message" lifeline; those are things the ATM displays, not participants.
-
"first displays menu" →
1 : displayMenu()ATM → Customer. -
"The Customer selects… the amount" →
2 : selectAmount(amount). -
"greater than the available balance" needs the
balance → call the database and get a dashed return
balance, then the ATM compares (self message). -
"tests whether sufficient cash is available" →
checkCash(amount)to the dispenser with returncashAvailable. -
"interacts with the database to debit" →
debit(accountNo, amount)+ return. -
"Then it dispenses cash and instructs the user" →
dispenseCashtheninstructTakeCash()back to the customer, in that order.
Second instructor example: Blackboard speech recognition (Ch.4 L2 solution)
The instructor's solution shows how an architectural pattern fixes the message pattern. Lifelines: Controller, Blackboard, Phrase Creation Agent, Word Creation Agent, Segmentation Agent.
The rhythm repeats three times: Controller
RequestSegmentation() → agent returns data →
Controller UpdateSegments() on the Blackboard →
dashed SegmentsUpdated() feedback. Then the same
for words and phrases, then CheckCompletion() and
Finalize(). Agents never message each other; all
shared data goes through the Blackboard. If your sequence
diagram has agent → agent arrows, it is no longer a
Blackboard.
5Final solved diagram
6Exam checklist
What do I look for in the scenario?
- Who starts it → actor
- "interacts with X" → lifeline X
- Each crossing verb → message
- Anything checked → return
Symbols I must remember
name : Classheads- Dashed lifelines
- Solid call ▶
- Dashed return
- Activation bars
- Self message loop
Most common mistakes
- Returns drawn solid
- Messages not numbered or out of order
- Agents talking directly in a Blackboard answer
- Treating displayed messages as lifelines
60-second check before submitting
- Messages read top to bottom = the scenario
- Every call that needs data has a return
- Active bars where objects are busy
Communication (collaboration) diagram
1What this diagram is for
Slide definition: the collaboration diagram is more focused on showing the communication between main entities. It carries the same messages as a sequence diagram, but instead of a time axis it shows who is linked to whom, with numbers giving the order. Your slides use both names: "Collaboration Diagram" in the title and "communication Diagram" in the explanation.
It belongs to the logical view as a dynamic diagram.
communication between entities/objects, links and messages, collaboration, which objects talk to each other. If a question stresses time order, choose sequence; if it stresses the network of objects, choose communication.
2Every symbol and notation
Object
- Looks like
- Rectangle with an underlined name (Account, ATM Machine, Bank Client).
- Means
- A participating object.
- Use it when
- For every entity in the interaction.
- Common mistake
- Adding attributes and operations like a class box.
Link
- Looks like
- Plain solid line between objects.
- Means
- A communication path along which messages travel.
- Use it when
- Between every pair of objects that exchange messages.
- Common mistake
- Sending a message between two objects with no link.
Numbered message
- Looks like
-
Small arrow beside a link plus
n : message(). - Means
- Direction and order of one message. Numbers replace the time axis.
- Use it when
- For every message; stack several on one link.
- Common mistake
- Unnumbered messages (the order is lost) or arrows pointing the wrong way along the link.
5 : Process Transaction()
3How to build it from a scenario or a sequence diagram
- List the participants exactly as you would lifelines.
- Draw one box per participant anywhere on the page; put the one that talks most in the middle (ATM Machine).
- Add a link for every pair that exchanges at least one message.
- Number the messages in scenario order (1, 2, 3…) and place each beside its link with an arrow toward the receiver.
- Check: reading the numbers in order must retell the scenario, like reading a sequence diagram top to bottom.
4Worked example: ATM withdrawal (instructor slide 7)
Reasoning
- Objects: Bank Client, ATM Machine, Account, Checking Account (the specialized account taking part in this scenario).
- Links: Client–ATM (all interaction with the user), ATM–Account (process transaction), Account–Checking Account (the actual withdrawal). There is no Client–Account link: the client never talks to the account directly, which is the architectural point the diagram makes.
- Numbering: 1–4 alternate on the Client–ATM link, 5 goes ATM → Account, 6 Account → Checking, 7 back, 8 back to ATM, 9–14 on the Client–ATM link again.
- Direction arrows group messages: everything the client sends (2, 4, 13) shares one arrow toward the ATM.
Converting from sequence: every sequence message becomes a numbered message on the link between the same two objects. That is why the two diagrams are interchangeable in exams that ask "draw the equivalent".
5Final diagram
6Exam checklist
What do I look for in the scenario?
- "communication between entities"
- Asked to convert a sequence diagram
Symbols I must remember
- Underlined object boxes
- Plain links
- Numbered messages with arrows
Most common mistakes
- No numbers
- Message with no link
- Adding a time axis or lifelines
60-second check before submitting
- Numbers in order retell the scenario
- Every message sits on a link
Component diagram
1What this diagram is for
Slide definition: a component diagram shows components of a system and required interfaces, ports, and relationships between them. Components are large replaceable software parts (ATM Machine, Bank Database, Blackboard, Controller). The diagram shows what each part offers (provided interface), what it needs (required interface) and how they plug together.
It supports the development view, which describes the static organization of modules (class libraries, subsystems, packages) from the implementation point of view, for programmers and project managers. In Chapter 4 it is the standard way to draw an architectural pattern.
components, interfaces, provided / required, modules, subsystems, libraries, development view, draw the component diagram using the [Blackboard / MVC / Broker…] pattern.
2Every symbol and notation
Component
- Looks like
-
Rectangle with
«component»and the name, plus the small component icon (box with two tabs) in the corner. - Means
- A modular, replaceable software unit.
- Use it when
- For each major part named by the scenario or the pattern's roles.
- Common mistake
- Drawing hardware (servers, PCs) as components. Hardware is a node in a deployment diagram.
Provided interface (lollipop)
- Looks like
-
A line from the component ending in a small circle (ball),
named with
I…. - Means
- Services this component offers to others. Slide: "Here's my data API (read/write/update)."
- Use it when
- For every service other components call on it.
- Common mistake
- Giving a provided interface to a component nobody calls.
Required interface (socket)
- Looks like
- A line ending in a half circle (cup).
- Means
- Services this component needs from someone else.
- Use it when
- When the scenario says X uses / depends on / calls Y.
- Common mistake
- Drawing the cup on the provider. The cup belongs to the user of the service.
Assembly connector (ball-and-socket)
- Looks like
- The cup of one component wrapped around the ball of another.
- Means
- A required interface is satisfied by a matching provided interface.
- Use it when
- Whenever you know which component provides what the other needs.
- Common mistake
- Ball and cup with different interface names.
Dependency between components
- Looks like
- Dashed arrow from the dependent to the component it uses.
- Means
- One component depends on another, without showing the interface.
- Use it when
- Simpler diagrams (ATM slide 12: Card Reader, Web Page, Client Desktop ⇢ Bank Database).
- Common mistake
- Arrow pointing from the provider to the user.
On the Blackboard slide the instructor notes that "agents can't access the blackboard" is the incorrect interpretation. Agents do access the Blackboard, through its interface, and only when the Controller schedules them. Control flow: Controller → Agents. Data flow: Agents ↔ Blackboard. Agents never talk to each other directly.
If the controller is active (offers scheduling, prioritizing, policies), give it a provided interface. If it is passive/hidden (only manages communication internally), give it no provided interface. Say which one you chose.
3How to extract a component diagram from a scenario
- Choose the pattern first. Component layout follows the architecture style. Activity 5 practises exactly this choice (Pipe-and-Filter, Blackboard, Peer-to-Peer, Client-Server, Broker, MVC).
- Components = the pattern's roles filled with scenario names. Blackboard: one Blackboard, one Controller, one component per knowledge source/agent.
- Provided interfaces: for each component, ask "what service does it offer?" Blackboard offers data read/write; each agent offers "run me".
- Required interfaces: ask "whom does it call?" Agents need the Blackboard. The Controller needs the agents and the Blackboard.
- Connect each socket to the matching ball with the same interface name.
- Check the pattern's rules: no direct agent-to-agent links in Blackboard; filters connect only through pipes; MVC views observe the model.
How each Activity 5 style shapes the component layout
| Style | Typical components | Interface shape to draw |
|---|---|---|
| Blackboard | Blackboard, Controller, Agents | Blackboard provides data API; agents provide service to controller; controller requires both (slide 12–13) |
| Pipes-and-Filters | Filters + a pipe mechanism |
In the video example each filter requires
IFileSystemPipe from a FileSystemManager
(slide 35)
|
| MVC | Model, Views, Controllers |
Model provides IModel and
IObservable; views provide
IObserver; controllers require
IModel (slide 10). Provide and require in
both directions because of the Observer two-way
dependency
|
| Broker | Client, ClientProxy, Broker, ServerProxy, Server, Bridge | Chain: Client requires ClientProxy; ClientProxy requires Broker; Broker requires ServerProxy; ServerProxy requires Server (slide 46) |
| Client-Server | Clients, Server | Server provides the service; clients require it; clients never talk to each other |
| Layered | One component per layer |
Each layer provides its interface
(IJSatcom, IJSecure,
IApplication, IHardware) and
requires the adjacent one (slide 16)
|
Peer-to-Peer appears in Activity 5 as a choice but has no component diagram in your slides.
4Worked example: Blackboard exercise, speech recognition (Ch.4 L2)
Reasoning, using the instructor's role table
- Components: Segmentation Agent (splits input into segments), Word Creation Agent (builds words from segments), Phrase Creation Agent (builds phrases from words), Controller (orchestrates agents and workflow), Blackboard (shared data memory). These are the five rows of the instructor's solution table.
- Blackboard is the only pure provider: read, write and event APIs. Every other component requires it.
- Each agent requires the Blackboard and provides its own service (segmentation, word creation, phrase creation) so the Controller can invoke it.
- Controller requires the three agent interfaces and the Blackboard. The instructor table marks it active ("provides control"); since no other component in this exercise calls it, no ball is drawn for it here.
- Rejected: links Segmentation → Word → Phrase. That would be Pipes-and-Filters. In a Blackboard, agents communicate only indirectly through the Blackboard.
The instructor also gives a "simple component diagram without interfaces" (agents —reads/writes→ Controller —controls→ Blackboard). The version below adds the provided/required interfaces from the same table, which is what full-mark answers usually expect.
5Final solved diagram
6Exam checklist
What do I look for in the scenario?
- Named pattern → its roles
- "offers / exposes" → provided
- "uses / needs / calls" → required
- "modules, libraries, subsystems"
Symbols I must remember
- «component» box + icon
- Ball = provided
- Cup = required
- Ball-in-cup assembly
- Dashed dependency
Most common mistakes
- Cup on the provider
- Hardware drawn as components
- Pattern rule broken (agent→agent)
- Confusing with deployment diagram
60-second check before submitting
- Every cup meets a ball with the same name
- Diagram still obeys the chosen pattern
- No nodes or artifacts here
Package diagram
The package diagram appears only by name: the development view is supported by "package diagrams and component diagrams", and packages are described as "building blocks that group classes". No package diagram is drawn or exercised. The symbols below are standard UML for recognition only.
1What this diagram is for
It groups classes into packages (folders of related classes) and shows which packages depend on which. Per your slides it helps analyze "how logical components map to physical files and directories", for programmers and software project managers.
2Symbols (standard UML)
Package
- Looks like
- Folder shape: rectangle with a small tab.
- Means
- A named group of classes or sub-packages.
- Use it when
- Organizing code into modules.
- Common mistake
- Confusing it with a component (a component is a deployable unit with interfaces).
Package dependency
- Looks like
- Dashed arrow between packages.
- Means
- Classes in one package use classes in another.
- Use it when
- Showing layering (UI → Logic → Data).
- Common mistake
- Cycles between packages.
3How to build it
- Group classes by responsibility (UI, transactions, data access).
- Name each package.
- Add dependencies in the direction of use; avoid cycles.
4Sketch based on the ATM classes
6Exam checklist
What do I look for in the scenario?
- "packages", "group classes", "code organization"
Symbols I must remember
- Folder tab
- Dashed dependency
Most common mistakes
- Mixing with component notation
60-second check before submitting
- Say it belongs to the development view
Deployment diagram
1What this diagram is for
Slide definition: a diagram used to model the physical structure of a software system. It shows hardware nodes (servers, PCs, phones, devices), the artifacts (executables, files) deployed on them, and the communication paths between nodes.
It is the only UML diagram of the physical view (deployment, configuration and installation), for system installers, administrators and system engineers. Your slides say this view is where you evaluate availability (redundant nodes), performance and scalability (processor speed, bandwidth) and security (firewalls).
A diagram of 3D boxes (console 1…n connected to a LAN server) was answered as a component diagram in the development view. The marker corrected it to deployment diagram, physical view and scored the part zero. 3D boxes are nodes; nodes mean hardware; hardware means the physical view. The follow-up parts on firewalls and availability were also physical-view reasoning.
hardware, servers, machines, devices, consoles, where the software runs / is installed, network, LAN, HTTP, firewall, redundant / backup server, physical view.
2Every symbol and notation
Node
- Looks like
- A 3D box (cube) with a name, optionally a stereotype like «device».
- Means
- A physical computing resource: PC, phone, server, ATM machine, console.
- Use it when
- For every piece of hardware or execution environment.
- Common mistake
- Reading 3D boxes as components (Major 1 mistake).
Artifact
- Looks like
-
Rectangle with
«artifact», a file name, and a small page icon. - Means
-
A physical file deployed on a node
(
web_server.exe). - Use it when
- When the question says which program runs where.
- Common mistake
- Drawing artifacts outside any node.
Communication path
- Looks like
-
Solid line between nodes, optionally labelled with the
protocol
«HTTP». - Means
- The nodes are physically or network connected.
- Use it when
- Every network link in the scenario.
- Common mistake
- Using component-style ball-and-socket between nodes.
Dependency
- Looks like
- Dashed arrow between nodes or artifacts.
- Means
- One depends on the other (Card_Reader ⇢ Bank_Database; pc_browser.exe ⇢ web_server.exe).
- Use it when
- When one part uses another's service.
- Common mistake
- Arrow direction reversed.
Deployment: physical deployment of artifacts on hardware; focus on nodes, physical distribution, communication links (web server, app server, DB server). Component: organization and dependencies among software components; focus on interfaces (authentication library, data access objects, business logic).
3How to extract a deployment diagram from a scenario
- Nodes: every machine or device named (PC, mobile phone, server, console, ATM).
- Artifacts: which program or file runs on which node, if stated.
- Paths: which nodes are networked; add the protocol if given.
- Quality requirements → hardware decisions. Security → add a firewall node on the path from outside. Availability → add a redundant/backup node. Performance → note processor/bandwidth or add nodes.
- Name the view: physical.
4Worked example: Major 1, Question 2
Reasoning, part by part
- Type and view: 3D boxes are nodes → deployment diagram, physical view.
- Structure: several consoles (client nodes) share one connection to a single LAN server; every console depends on that server.
- Modify for remote access + firewall: add a remote employee device node outside the organization, a Firewall node, and route the path remote device → firewall → LAN server. The firewall sits between outside and inside so all incoming and outgoing traffic passes through it. Rejected: connecting the remote device directly to the LAN server; that ignores "controlling traffic".
- Availability: poor. The LAN server is a single point of failure: if it crashes, every console loses service and there is no backup.
- Improve: add a redundant (backup) LAN server node that takes over on failure. Your physical-view slide gives exactly this example: "specifying the need for redundant nodes to increase the system's availability".
5Final solved diagram
Second instructor example: Client-Server deployment with artifacts (Ch.4 L2 slide 41)
6Exam checklist
What do I look for in the scenario?
- Hardware, devices, servers
- Where software is installed
- Security → firewall
- Availability → redundant node
Symbols I must remember
- 3D node box
- «artifact» with page icon
- Solid path + «protocol»
- Dashed dependency
Most common mistakes
- Calling nodes components (Major 1)
- Naming the development view instead of physical
- Firewall not on the outside path
- No backup for a single point of failure
60-second check before submitting
- Every node is hardware
- External traffic crosses the firewall
- View named: physical
State machine diagram
Named only. Slide 5 lists the state diagram among the logical view's dynamic diagrams, and the summary table (slide 18) puts "State" under Logical. The extra slide 17 lists "State Machine Diagram (object life cycles)" under the Process view. If asked for the view, say logical (per the main table) and mention the process view listing. No notation or example is given; symbols below are standard UML.
1What this diagram is for
Per slide 17: the life cycle of an object, meaning the states it can be in and the events that move it between states.
2Symbols (standard UML)
State
- Looks like
- Rounded rectangle with a state name.
- Means
- A condition the object stays in (Idle).
- Use it when
- Nouns/adjectives describing status.
- Common mistake
- Writing actions as states.
Transition
- Looks like
- Arrow labelled
event [guard]. - Means
- The event that moves the object to a new state.
- Use it when
- "when…", "after…".
- Common mistake
- Unlabelled transitions.
Initial / final
- Looks like
- Filled dot to start; bullseye to end.
- Means
- Where the life cycle begins and ends.
- Use it when
- Always.
- Common mistake
- Missing initial state.
Interaction overview diagram
Named only: "The UML activity diagram and interaction overview diagram support [the process] view", described in slide 17 as "high-level control of interactions". No notation or example. Symbols below are standard UML.
1What this diagram is for
An activity-diagram-shaped map whose nodes are whole interactions (usually references to sequence diagrams). Use it to show which interaction happens after which, and under what condition.
2Symbols (standard UML)
Interaction reference
- Looks like
-
Frame with
refin the corner and the name of a sequence diagram. - Means
- "Run that whole interaction here."
- Use it when
- Each major scenario step.
- Common mistake
- Drawing messages inside instead of referencing.
Decision, start, end, flows
- Looks like
- Same as the activity diagram.
- Means
- Control between interactions.
- Use it when
- Branching between scenarios.
- Common mistake
- Missing guards.
Compare and choose
AComparison table
| Diagram | Main purpose | Static / dynamic | Architectural view | Main symbols | Typical exam trigger words | Commonly confused with |
|---|---|---|---|---|---|---|
| Class | Classes, attributes, operations and their relationships | Static | Logical | Class box, association, multiplicity, △, ◇, ◆, dashed dependency | classes, attributes, relationships, stores records | Object, Component |
| Object | Snapshot of instances and links | Static | Logical | Underlined name : Class, links | instance, at a moment, specific values | Class |
| Use case | Actors and the system goals they achieve | Behavioral | +1 Scenario (user) | Actor, ellipse, boundary, «uses», «extends» | actors, users, functionality, what users can do | Activity (steps) |
| Activity | Workflow of actions with decisions and parallelism | Dynamic | Process | ● start, action, ◇ decision/merge, ▬ fork/join, ◉ end, lanes | workflow, process steps, if/otherwise, flow | Sequence, State |
| Sequence | Messages between participants in time order | Dynamic | Logical | Lifeline, call ▶, dashed return, activation, self message | messages over time, order of interactions | Communication, Activity |
| Communication | Messages along links between objects, numbered | Dynamic | Logical | Object, link, numbered message | communication between entities, collaboration | Sequence |
| Component | Software components and their provided/required interfaces | Static | Development | «component», lollipop, socket, assembly, dependency | components, interfaces, pattern structure, modules | Deployment, Package |
| Package | Grouping of classes into packages | Static | Development | Folder, dependency | packages, group classes, code organization | Component |
| Deployment | Hardware nodes, deployed artifacts, network paths | Static | Physical | 3D node, «artifact», path «HTTP» | hardware, servers, devices, firewall, backup server | Component |
| State machine | Life cycle of one object | Dynamic | Logical (table) / Process (slide 17) | State, transition, start/end | states, life cycle, status changes | Activity |
| Interaction overview | Control flow between whole interactions | Dynamic | Process | ref frames + activity notation | high-level control of interactions | Activity, Sequence |
BHow do I know which UML diagram the question wants?
classes, attributes, relationshipsClass diagram
messages over time, order of interactionsSequence diagram
workflow, process steps, if… otherwise…Activity diagram
software components and interfaces, apply the [pattern]Component diagram
deployment onto hardware / nodes, servers, firewallDeployment diagram
actor goals and system functionality, what each user can doUse case diagram
communication between main entities, numbered messagesCommunication diagram
a specific instance at a momentObject diagram
life cycle, states of an objectState machine diagram
group classes into packages, code organizationPackage diagram
1. Structure or behavior? Things and connections → class, object, component, package, deployment. Things happening → use case, activity, sequence, communication, state. 2. Which layer? Code classes → class. Software parts with interfaces → component. Hardware → deployment. User goals → use case. Order of messages → sequence. Order of actions → activity.