In the world of software architecture and system design, it is a common mistake to reach for a specific diagram type out of habit. You might instinctively reach for a Class Diagram because you are used to it, or a Sequence Diagram because you are focused on code. However, effective modeling requires a different approach: diagram selection based on inquiry.

This tutorial explores the “Diagram Selection Rule,” a methodology that dictates you should start with a specific user goal or architectural question and then select the simplest diagram capable of answering it. We will walk through the seven distinct categories of diagrams, explain the specific questions they answer, and provide practical examples using Visual Paradigm.

The Golden Rule: Pick the Simplest Diagram

Before diving into specific diagram types, we must establish the guiding principle. A diagram should never be created just to document the system; it should be created to reduce ambiguity.

Visual Paradigm excels at this because it allows you to quickly prototype and switch between views. However, the tool is only as good as the question you ask it. The rule is simple: Pick the simplest diagram that answers your question.

1. The Use Case Diagram: Defining Boundaries

When you start a project, the scope is often vague. You might not know exactly who interacts with the system or what the system’s primary responsibilities are. In this phase, you are dealing with stakeholders and goals.

If you find yourself asking, “Who can approve an order?” or “What are the high-level goals of the system?”, you need a Use Case Diagram.

• Question to Answer: Are system boundaries or stakeholder goals unclear?
• Key Elements: Actors (stick figures) and Use Cases (ovals).
• Visual Paradigm Tip: Use the “Actor” tool to define external entities and the “Use Case” tool to define system functions. Connect them to visualize the scope of interaction.

Example Scenario: User Authentication

Imagine you are modeling a login system. You realize you don’t know if an “Administrator” or a “Guest” can access the profile settings.

@startuml
left to right direction
actor "Guest" as G
actor "Administrator" as A
rectangle "System" {
  usecase "Login" as UC1
  usecase "View Profile" as UC2
}
G --> UC1
A --> UC1
A --> UC2
@enduml

Here, the Use Case diagram clarifies that while everyone can login, only the Administrator can view the profile. This answers the “Who” question immediately.

2. The Activity Diagram: Mapping Workflows

Once you understand who does what, you need to understand how they do it. Real-world business processes are rarely linear. They involve decisions, parallel tasks, and handoffs between departments or systems.

If your question is “How does the system handle a payment failure?” or “What are the steps involved in shipping an order?”, you need an Activity Diagram.

• Question to Answer: Are there steps, decisions, parallel work, or handoffs?
• Key Elements: Actions (rounded rectangles), Decisions (diamonds), and Flow Objects.

Example Scenario: Order Processing Logic

An activity diagram allows you to visualize the logic flow, including the “fork” where parallel processes (like sending an email and updating inventory) happen simultaneously.

@startuml
start
:Receive Order;
if (Inventory Available?) then (Yes)
  :Reserve Inventory;
  :Process Payment;
else (No)
  :Notify Customer;
endif
:Ship Order;
stop
@enduml

In Visual Paradigm, you can drag and drop these elements to create a flowchart that maps the exact decision tree of your business logic.

3. The Sequence Diagram: Modeling Collaboration

When the focus shifts from “what is happening” to “who is talking to whom,” you need to model the interaction. This is crucial when multiple objects, services, or external APIs must collaborate to fulfill a single user request.

If your question is “Which component handles the error message when the API times out?”, you need a Sequence Diagram.

• Question to Answer: Do multiple objects, services, APIs, or external systems collaborate?
• Key Elements: Lifelines (vertical dashed lines), Messages (arrows), and Activation Bars.

Example Scenario: API Collaboration

Sequence diagrams are perfect for showing the chronological order of messages passed between a Client, a Service, and a Database.

@startuml
participant "Client" as C
participant "Service" as S
participant "Database" as D

C -> S : Request Data
activate S
S -> D : Query DB
activate D
D --> S : Data
deactivate D
S --> C : Response
deactivate S
@enduml

This visualizes the exact sequence of calls, helping you identify bottlenecks or potential race conditions in your architecture.

4. The Class Diagram: Extracting Stable Concepts

After understanding the behavior, you must define the structure. This is where you determine the “stable concepts” of your system. This diagram is essential when the team is debating the responsibilities of entities or the ownership of data.

If your question is “Which component owns inventory reservation?”, you need a Class Diagram.

• Question to Answer: Are entities, responsibilities, relationships, or data ownership unclear?
• Key Elements: Classes (rectangles with attributes and methods), Associations, and Inheritance.

Example Scenario: Entity Ownership

Class diagrams define the contract of your software. They specify the data types (UUID, String, Money) and the relationships between them.

@startuml
class Order {
  +id: UUID
  +date: Date
  +status: String
}
class Customer {
  +id: UUID
  +name: String
}
class Payment {
  +id: UUID
  +amount: Money
}

Order "1" -- "1" Customer
Order "1" -- "1" Payment
@enduml

By defining these classes, you resolve the ambiguity of data ownership. The Order class clearly knows which Customer it belongs to, and the relationship is explicitly defined.

5. The Component Diagram: Showing Architectural Boundaries

As the system grows, you move from individual classes to modules and services. You need to understand the high-level architectural boundaries, dependencies, and interfaces.

If your question is “Where is the payment service deployed?” or “Which module depends on the logging service?”, you need a Component Diagram.

• Question to Answer: Do modules, services, interfaces, or dependencies need clarification?
• Key Elements: Components (rectangles with the component icon), Interfaces (lollipop symbols), and Dependencies (dashed arrows).

Example Scenario: Service Dependencies

This diagram helps visualize the “big picture” of how your system is built. It abstracts away the internal details of classes and focuses on how major subsystems interact.

@startuml
package "Frontend" {
  component "Web UI" as WebUI
}
package "Backend" {
  component "Order Service" as OrderSvc
  component "Payment Service" as PaySvc
}

WebUI --> OrderSvc
OrderSvc ..> PaySvc : uses
@enduml

Here, you can clearly see that the Web UI talks to the Order Service, which in turn uses the Payment Service. This clarifies the architectural boundaries.

6. The Deployment Diagram: Showing Runtime Placement

Finally, you must consider the physical or virtual infrastructure. How does the software actually run? Where are the containers? How are the services networked?

If your question is “Where is the payment service deployed?” or “Do we need scaling for the database?”, you need a Deployment Diagram.

• Question to Answer: Do deployment, networking, scaling, containers, devices, or infrastructure matter?
• Key Elements: Nodes (servers, cloud icons), Devices, and Communication Paths.

Example Scenario: Infrastructure Mapping

Deployment diagrams map the software artifacts to the hardware nodes. This is critical for DevOps and infrastructure planning.

@startuml
node "Cloud Server" as CS {
  node "App Server" {
    node "Order Service" {
      artifact "Order.jar"
    }
    node "Payment Service" {
      artifact "Payment.jar"
    }
  }
}
node "Database" as DB {
  artifact "PostgreSQL"
}
CS --> DB
@enduml

This diagram answers the question of placement. You can see that the Order Service and Payment Service are running on the same cloud server, which might be a decision you want to revisit for security or performance reasons.

7. The State Machine Diagram: Modeling Lifecycle Rules

Some objects have complex lifecycles. They don’t just exist; they transition through various states based on events. This is crucial for objects like Orders, Tickets, or User Accounts.

If your question is “Which transitions are valid for an order?” or “Can an order be cancelled after it’s shipped?”, you need a State Machine Diagram.

• Question to Answer: Does an object behave differently depending on its current state?
• Key Elements: States (rounded rectangles), Transitions (arrows), and Events (triggers).

Example Scenario: Order Lifecycle

This diagram prevents logical errors by defining exactly how an object can change state. It ensures that you don’t accidentally try to “Cancel” an order that is already “Shipped”.

@startuml
[*] --> Idle
Idle --> Processing
Processing --> Done
Processing --> Idle

state "Processing" as P
state "Done" as D
@enduml

In this simplified example, we see the transitions. A state machine diagram would typically list the events (e.g., “On Cancel”, “On Ship”) that trigger these transitions.

Conclusion: The Question-Driven Approach

By following the “Diagram Selection Rule,” you transform your modeling process from a rote exercise into a strategic one. Instead of drawing diagrams because you have to, you draw them to answer specific, high-value questions. Whether you are clarifying boundaries with a Use Case diagram or mapping infrastructure with a Deployment diagram, always start with the question.

Remember: Create a diagram only when it answers a question or reduces ambiguity. This principle ensures your architectural documentation remains concise, relevant, and actionable.