UML

Unified Modeling Language

UML 2.0

Used to visualize, design, and document software systems.

1. Structural Diagrams
Describe the static parts of the system — what it is.

Diagram Purpose When to Use

🧱 Class Shows system structure: classes, Software design,

Diagram attributes, relationships planning OOP
structure

👥 Use Case Shows how users interact with Early planning,

Diagram the system stakeholder discussion

🧩 Component Shows components/modules Microservices,

Diagram and dependencies system-level view

🖥 Deployment Shows system infrastructure DevOps, infrastructure

Diagram (servers, nodes) planning

📍 Object Snapshot of objects (instances) Debugging, test

Diagram at a moment planning

⚙️ Package Organizes code into Clean architecture,

Diagram packages/modules large projects

2. Behavioral Diagrams
Describe the dynamic parts — what it does.

Diagram Purpose When to Use

📦 Sequence Shows how objects interact Explaining backend
Diagram over time flow (e.g. API call)

📊 Activity Diagram Shows flow of control or Modeling logic,

business logic automation, workflows

🔁 State Diagram Shows states of an object UI, sessions, finite state

and transitions machines

🧪 Interaction Overview of how High-level flow

Overview interactions happen visualization

🧪 Communication Alternative to sequence Less common

Diagram diagram (object focus)

Key Diagrams
Class Diagram(Exercised)
A Class Diagram is fundamental for modeling the static structure of
your system. It shows how different classes are structured, what their
attributes and methods are, and how they are related to each other (via
inheritance, association, or composition).

Example: E-commerce System

Explanation:

●​ Product: Represents an individual product in the e-commerce

store. It has attributes like id, name, and price. The getDiscount()
method returns the discount applicable to the product.​

●​ Category: Represents a product category (e.g., Electronics,

Clothing). The getProducts() method returns a list of products in
that category.​

●​ ShoppingCart: Represents a user's shopping cart, where products

are added or removed. It has a collection of Product objects and
calculates the total price.​

●​ Order: Represents a finalized order, containing multiple products.

The addItem() method adds a product to the order.​

Relationships:

●​ 1..* (One-to-Many) between Product and Category: A product

belongs to a category, but a category can have multiple products.​

●​ 1..* (One-to-Many) between Order and Product: An order can

contain multiple products, and a product can be part of many
orders.

Use Case Diagram(Exercised)

consists of a system (represented by a large box), actors (represented by small
stylized men out of the box), actions (represented by ellipses within the box)
and relations (edges or arcs linking actors with actions, actors with actors,
actions with actions).

✅ 1. Inclusion Association (<<include>>)

Use when: A common behavior is reused in multiple use cases.

Think of it as: “Always include this behavior when doing that.”

🔹 Example:
In your vending machine:
 ●​ Use Case: "Buy Item"​

●​ Includes: "Select Item" and "Insert Money"​

This means "Buy Item" always includes selecting and paying.

✅ 2. Extension Association (<<extend>>)

Use when: A use case optionally adds extra behavior to another use
case.

Think of it as: “Sometimes, this extra thing might happen.”

🔹 Example:
●​ Use Case: "Buy Item"​

●​ Extended by: "Request Refund" (if user cancels or machine fails)

✅ 3. Multiplicities
Use to show: How many instances of an actor or use case can be
involved.

🔹 Example:
●​ A user can buy many items → 1..*​

●​ A technician services one or zero machines at a time → 0..1​

You'd mark that like this near the actor or association:

Customer (1..*)

Technician (0..1)

Example: E-commerce System (Advanced)

Explanation:

●​ Actors:​

○​ Customer: A person using the e-commerce platform.​

●​ Use Cases:​

○​ Browse Products: The customer can browse through

various products available.​

○​ Add to Cart: The customer can add products to their

shopping cart.​

○​ Checkout: The customer can proceed to checkout and

purchase items in the cart.​

○​ Make Payment: The customer can complete payment for

their order.​

○​ Confirm Order: The system confirms the order once

payment is successful.​
 ○​ Manage Account: Customers can update their personal
account information, like changing their password.​

○​ View Order History: Customers can see past orders and

their status.​

Relationships:

●​ Associations: Represent interactions between actors and use

cases.​

●​ The Customer interacts with all the use cases related to

shopping, such as browsing products, adding to the cart, and
completing the checkout process.

Sequence Diagram (Exercised)

These are similar to two-dimensional Euclidean planes, the horizontal
axis marking labels for a finite set of actors and system components,
and the (downward) vertical axis representing time. Actors and
components are usually derived from a use case diagram. Actions are
split into messages going back and forth between actors and
components. Messages are represented by horizontal arrows. There are
two types of messages:

synchronous (the initiator of the message is blocked until a return value

is sent back from the message recipient) and asynchronous (the
initiator is not blocked and any return value must be carried by a later
message where the initiator is the recipient of the asynchronous
message).

🧠 What It's Talking About:

📉 The "plane" (diagram layout):
●​ Horizontal axis = actors/components (e.g. User, Vending Machine,
Payment System)​

●​ Vertical axis (downward) = time passing​

 Imagine time flows downward. The further down an action is
placed, the later it happens.

📨 Messages:
Actors/components send messages (actions) to each other. These are
shown as horizontal arrows going from one participant to another.

There are two types of these arrows (messages):

1. Synchronous message:

●​ Sender waits for the response (gets blocked).​

●​ Like a function call in programming.​

●​ Example:​
"User requests to pay" → system processes payment → then
replies "Payment successful".​

📤 Sender blocks ⏳ until 📥 reply arrives.

2. Asynchronous message:

●​ Sender doesn't wait for a response (not blocked).​

●​ Like starting a background task.​

●​ If a reply is needed, it comes later as a separate message.​

📤 Sender continues working 🚀 without waiting.

🧪 Example (Vending Machine):
Tim Actor Component Actio
e n

t1 User → Vending Machine selectItem() (sync)

t2 Vending Machine → processPayment()
Payment Service (async)

t3 Payment Service → Vending paymentConfirmed()

Machine (async reply)

t4 Vending Machine → User dispenseItem() (sync)

Example: Checkout Process (Advanced)

Explanation:

●​ Customer initiates the checkout process by clicking the "Checkout"

button.​

●​ WebApp calls CartService to retrieve items in the cart.​

●​ CartService queries the database for the cart items and sends
them back to the WebApp.​

●​ The WebApp then calls the PaymentGateway to process the

payment.​

●​ If the payment is successful, the WebApp triggers the

OrderService to create an order.​

●​ Finally, the WebApp confirms the order details to the customer.

State Diagram (Exercised)
State diagrams are similar to state automata, and are used to describe
the logic behind any state change within a system or a system
component. States are represented by rounded-corner boxes with a
label (the state name); a change from state A to state B is represented
by an arrow from A to B. Two types of states, “start” and “end”, are such
that there are no incoming arrows into “start” and no outgoing arrows
from “end” states. Arrows are labelled by the name of the activity that
caused the state change.

Activity Diagram(Exercised)
An Activity Diagram shows the flow of control through a system,
including the conditions, loops, and concurrency (parallel actions). It’s
often used for modeling business processes or workflows.

Another type of state diagram, called activity diagram, emphasizes

activities rather than states: activity names label the round-cornered
boxes, and the state names label the arrows. Apart from “start” and “end”
nodes, activity diagrams also have special “test” nodes represented by
small rhombi.

Example: Order Fulfillment Process (Advanced)

Explanation:

●​ The process starts with checking payment status.​

●​ If the payment fails, the system notifies the admin and ends.​

●​ If the payment is successful, the order is fulfilled and shipped.​

●​ After the shipping process, the system ends.

Deployment Diagram
A Deployment Diagram shows how software components are deployed
to physical hardware and infrastructure. It is crucial for understanding
how your system will run in a distributed or cloud environment.

Example: Microservices-based E-commerce (Advanced)

Explanation:

●​ Web Server: The front-end web server (using Nginx or Apache)

serves static files (HTML, CSS, JS).​

●​ WebApp: A React/Node.js application running in a container on

the server.​

●​ Microservices:​

○​ Cart Service: Handles the shopping cart logic.​

○​ Order Service: Manages order creation and status tracking.​

○​ Payment and Shipping Services: Deal with payment

processing and shipping logistics, respectively.

Pro Tip for CTOs

●​ Complex systems benefit from clear, concise UML diagrams to

reduce ambiguity during communication with developers, product
managers, and stakeholders.​
●​ Start simple, and then gradually build more complex diagrams as
your system evolves.​

●​ Ensure scalability and maintainability are always considered in

your design.