Introduction to UML

Unified Modeling Language (UML) is a standardized modeling language consisting of an integrated set of diagrams, developed to help system and software developers for specifying, visualizing, constructing, and documenting the artifacts of software systems.

Why UML?

• Visualize: Communicate structure and behavior.
• Specifying: Detailed design work.
• Documenting: Maintaining a record of decisions.

What we will cover

In this course, we will dive deep into:

• Structural Modeling: Class, Component, and Deployment Diagrams.
• Behavioral Modeling: Use Case, Sequence, Activity, and State Machine Diagrams.
• Design Decisions: How to choose between attributes and entities, and how to map models to code.

By the end of this course, you’ll be able to architect complex systems with clarity and precision.

Modeling with PlantUML

Instead of using drag-and-drop tools that can be tedious to update, we use PlantUML. PlantUML is an open-source tool that allows users to create UML diagrams from a plain text language.

Why Text-Based Modeling?

• Version Control: Since it’s text, you can track changes using Git.
• Speed: Quickly iterate on designs without fighting with mouse alignments.
• Consistency: The tool handles the layout automatically.

Basic Syntax Structure

Most diagrams start with a keyword defining the type (though often omitted in the specific component syntax we use here) and use simple arrows to define relationships.

Common Symbols

Symbol	Meaning
->	Solid line/arrow
-->	Dashed line/arrow
:	Adds text to a line/relationship
as	Alias for a long name
[ ]	Represents a component or node
( )	Represents a use case

Tips for Efficient Modeling

1. Focus on Semantics: Let PlantUML handle the layout. Don’t spend too much time trying to force specific positioning unless necessary.
2. Use Aliases: For long component names, use as to keep your code clean.

   participant "Very Long Service Name" as Service
   User -> Service: Request
   

3. Colors and Styling: You can add skinparams or inline colors, but keep it simple for technical documentation.

   node "Server" #LightBlue
   

Live Preview

In most modern IDEs (like VS Code), you can install the PlantUML extension to see a live preview of your diagrams as you type.

Class Diagrams

Class diagrams are the foundational structural diagrams in UML. They represent the static view of a system, detailing classes, their internal structure, and how they relate to one another.

1. Anatomy of a Class

A class is represented as a box with three compartments:

1. Top: Class Name (Bold, centered, Italics if Abstract).
2. Middle: Attributes (Fields/Variables).
3. Bottom: Operations (Methods/Functions).

Visibility Modifiers

• + Public: Accessible from anywhere.
• - Private: Accessible only within the class.
• # Protected: Accessible within class and subclasses.
• ~ Package/Internal: Accessible within same package.

2. Relationships and Arrows

Understanding relationships is the core of UML. The arrow style defines the semantics.

Relationship	Notation	Meaning	Property
Generalization	Solid line + Hollow Triangle	Dog is an Animal.	Inheritance
Realization	Dashed line + Hollow Triangle	ArrayList implements List.	Interface implementation
Association	Solid line (opt. arrow)	Teacher has Students.	General link
Aggregation	Hollow Diamond	Car has Wheels.	”Part-of” (Weak: Parts can exist alone)
Composition	Filled Diamond	Building has Rooms.	”Part-of” (Strong: Parts die with parent)
Dependency	Dashed Arrow	A uses B.	Temporary usage (parameter/local)

Multiplicity

Multiplicity defines how many instances of one class link to one instance of another:

• 1: Exactly one.
• 0..1: Zero or one.
• * or 0..*: Zero or more.
• 1..*: One or more.

3. Decisions: Attribute vs. Entity?

A common dilemma: Should something be an attribute of a class or its own entity (class)?

• Attribute: If the data is a simple value (string, number, date) that doesn’t have its own identity or lifecycle. E.g., String address.
• Entity: If the data has its own properties, needs to be shared among multiple objects, or has a complex lifecycle. E.g., Address as a class if you need to track Street, City, and Zip separately or validate them.

4. Comprehensive Example

PlantUML Code:

interface Playable {
  +play()
}

abstract class Instrument {
  -String brand
  #float price
  {abstract} +tune()
}

class Guitar extends Instrument implements Playable {
  -int stringCount
  +play()
  +tune()
}

class Case {
  -String material
}

Guitar "1" *-- "1" Case : has >
Guitar "1" o-- "0..*" String : uses >

Mapping to Code (Java)

public interface Playable {
    void play();
}

public abstract class Instrument {
    private String brand;
    protected float price;
    public abstract void tune();
}

public class Guitar extends Instrument implements Playable {
    private int stringCount;
    private Case storageCase = new Case(); // Composition

    public void play() { /* ... */ }
    public void tune() { /* ... */ }
}

Sequence Diagrams

Sequence diagrams are interaction diagrams that show how objects operate with one another and in what order. They are time-centric, showing the chronological sequence of messages.

1. Key Components

• Lifelines: Represented by vertical dashed lines. They represent the existence of an object over time.
• Activations/Execution Bars: Thin rectangles on the lifeline showing when an object is actively processing a request.
• Actors: Stick figures representing external entities (users, other systems).

2. Message Types

The arrow heads matter significantly:

Symbol	Message Type	Description
->	Synchronous	Caller waits for a response before continuing. (Full arrowhead)
->>	Asynchronous	Caller continues without waiting for response. (Open arrowhead)
-->	Return	Response sent back to the caller. (Dashed line)
-> (to self)	Self-Message	A method call within the same object.

3. Combined Fragments (Logic Control)

Sequence diagrams use “fragments” to handle logic:

• alt (Alternative): If/else logic. Only one branch executes.
• opt (Optional): If then. Executes only if condition is true.
• loop (Iteration): Repeats a sequence of messages.
• par (Parallel): Messages that happen concurrently.

4. Detailed Example

PlantUML Code:

actor User
participant "Web UI" as UI
participant "Auth Service" as Auth
database DB

User -> UI: Enter Credentials
UI -> Auth: login(user, pass)
activate Auth
  Auth -> DB: findUser(user)
  activate DB
    DB --> Auth: userPayload
  deactivate DB
  
  alt #LightGreen credentials valid
    Auth --> UI: token
    UI --> User: Dashboard
  else #Pink invalid
    Auth --> UI: error 401
    UI --> User: Show error message
  end
deactivate Auth

Conceptual Check

In a sequence diagram, what does a dashed arrow (-->) usually represent?

An asynchronous message

A return message/response

A class dependency

A parallel process

Verify Prediction

Use Case Diagrams

Use Case diagrams describe the high-level functional requirements of a system. They show what a system does, not how it does it.

1. Key Elements

• Actors: External entities that interact with the system (stick figures). Can be humans or other systems.
• Use Cases: Specific tasks or functions the system performs (ovals).
• System Boundary: A box defining the scope of the system.
• Associations: Lines connecting actors to use cases.

2. Advanced Relationships

Use cases can relate to each other:

• <<include>>: One use case must include another to complete its task.
  • Example: “Withdraw Cash” <<include>> “Authenticate User”.
• <<extend>>: One use case optionally adds behavior to another under specific conditions.
  • Example: “Calculate Tax” <<extend>> “Place Order” (only if tax applies).

3. Decisions: Actor or Use Case?

• Actor: Is it outside the system boundary? Does it initiate or receive something?
• Use Case: Is it a goal the actor wants to achieve?

4. Example

PlantUML Code:

left to right direction
actor "Customer" as c
actor "Bank Clerk" as b

rectangle "ATM System" {
  c -- (Withdraw Cash)
  c -- (Check Balance)
  (Withdraw Cash) ..> (Authenticate) : <<include>>
  (Check Balance) ..> (Authenticate) : <<include>>
  (Withdraw Cash) <.. (Print Receipt) : <<extend>>
  b -- (Maintenance)
}

Activity Diagrams

Activity diagrams are essentially advanced flowcharts. They model the flow of control from one activity to another, supporting parallel behavior and complex logic.

1. Basic Symbols

• Start Node: A solid black circle.
• End Node: A bullseye (circle with a dot).
• Activity/Action: Rounded rectangle.
• Control Flow: Solid arrow.

2. Control Nodes

• Decision Diamond: One input, multiple outputs with [guards].
• Merge Diamond: Multiple inputs, one output (ends a decision).
• Fork (Split): A thick horizontal or vertical bar. One input splits into multiple parallel paths.
• Join: A thick bar where parallel paths merge back into one.

3. Swimlanes (Partitions)

Swimlanes group activities based on who performs them (e.g., “User”, “System”, “Database”).

4. Example: Order Processing

PlantUML Code:

|Customer|
start
:Place Order;
|Order System|
:Validate Order;
if (Order Valid?) then (yes)
  fork
    :Process Payment;
  fork again
    :Prepare Shipping;
  end fork
  :Ship Goods;
  stop
else (no)
  :Notify Error;
  stop
endif

Decisions: Activity vs. State?

• Activity: Focuses on the flow of work (what happens). Use when describing a process/algorithm.
• State: Focuses on the lifecycle of an object (what it is). Use when an object’s behavior changes based on its current condition.

State Machine Diagrams

While Activity Diagrams show the flow of a process, State Machine Diagrams (or Statecharts) show the lifecycle of a single object as it transitions between states in response to events.

1. Key Components

• State: A rounded rectangle representing a stable condition of an object (e.g., Idle, Pending, Processing).
• Transition: An arrow from one state to another.
• Event (Trigger): The occurrence that causes a transition (e.g., buttonClicked, timeout).
• Guard: A boolean condition [condition] that must be true for the transition to occur.
• Action: An operation / action() performed during the transition.

2. Transition Syntax

Event [Guard] / Action

3. Example: Document Lifecycle

PlantUML Code:

[*] --> Draft
Draft --> Submitted : submit()
Submitted --> Published : approve() [isUserAdmin]
Submitted --> Draft : reject()
Published --> Archived : archive()
Archived --> [*]

4. Implementation Tip

State machines are often implemented in code using the State Design Pattern, where each state is a class, or a simple switch-case if the logic is simple.

Architectural Diagrams

These diagrams shift focus from code structure to the physical and logical organization of the system.

1. Component Diagrams

A Component is a modular part of a system that encapsulates its contents and whose manifestation is replaceable.

Symbols

• Component: A box with two small rectangles on the left or a stereotype <<component>>.
• Provided Interface: “Lollipop” symbol (circle on a line). The services the component offers.
• Required Interface: “Socket” symbol (half-circle). The services the component needs.

PlantUML Code:

package "Order System" {
  [Order Logic] --() IOrder
  [Payment Service] --() IPayment
}
[Web UI] ..> IOrder : use
[Order Logic] ..> IPayment : use

---

2. Deployment Diagrams

These diagrams show the physical hardware and software mapping.

Symbols

• Node: A 3D cube representing a physical or virtual machine (e.g., “Web Server”, “Database”).
• Artifact: A physical file (JAR, DLL, script) deployed on a node.
• Communication Path: A line representing the protocol (e.g., SSH, HTTP).

Example

PlantUML Code:

node "Application Server" {
  artifact "OrderService.jar"
}
node "Database Server" {
  database "PostgreSQL"
}
"Application Server" -- "Database Server" : JDBC / TCP:5432

Decisions: Component or Node?

• Component: Logical unit of code/functionality.
• Node: Physical or virtual environment where components “live”.

Designing with UML: Best Practices

Modeling is not just about drawing; it’s about making architectural decisions. Here is how to navigate common design challenges.

1. The “Attribute vs. Entity” Decision

When modeling a piece of data (e.g., Address), ask:

• Does it have its own identity? If yes -> Entity (Class).
• Does it need its own validation or logic? If yes -> Entity.
• Is it a primitive value? If yes -> Attribute.
• Can it change independently of its container? If yes -> Entity.

2. Choosing the Right Diagram

Don’t use every diagram for every feature. Pick based on what you need to communicate:

Goal	Diagram Type
High-level requirements	Use Case
Logic/Workflows	Activity
Static structure/Database	Class
Time-sensitive interaction	Sequence
Complex object lifecycle	State Machine
System deployment/Network	Deployment

3. Granularity: How much detail?

• Analysis Level: Focus on concepts and domain. Ignore technical details like ID fields or getters/setters.
• Design Level: High detail. Include types, visibility, and specific design patterns (e.g., Singleton, Factory).

4. Mapping UML to Implementation

• Generalization maps to extends.
• Realization maps to implements.
• Composition is usually implemented as a field initialized in the constructor.
• Aggregation is usually a field passed in via a setter or constructor parameter.
• State Machines map well to the State Pattern.
• Activity Flows map to method logic or Chain of Responsibility.

5. The Power of Code (PlantUML)

Always prefer text-based modeling over graphical tools for:

• Maintainability: Changing a relationship is a text edit, not a mouse struggle.
• Consistency: High-quality diagrams every time.
• Collaboration: Easy to review design changes in pull requests.

Summary Checklist

1. Identify the Actors and their Goals.
2. Define the Domain Model (Classes and their core relationships).
3. Visualize Critical Paths (Sequence diagrams for complex interactions).
4. Map to Physical Architecture (Deployment).
5. Iterate! UML is meant to be a living document during the design phase.