Definition: UML is a standardized visual language for modeling software systems, showing structure, behavior, and interactions.
Why Use UML?
- Visualize system architecture
- Communicate design decisions
- Document software structure
- Plan before coding
UML Diagram Types
1. Class Diagram
Shows classes, attributes, methods, and relationships.
classDiagram
class Vehicle {
-string brand
-int year
+start()
+stop()
}
class Car {
-int doors
+openTrunk()
}
class Motorcycle {
-bool hasSidecar
+wheelie()
}
Vehicle <|-- Car
Vehicle <|-- Motorcycle
2. Sequence Diagram
Shows interactions between objects over time.
sequenceDiagram
participant User
participant System
participant Database
User->>System: Login Request
System->>Database: Validate Credentials
Database->>System: User Data
System->>User: Login Success
3. Use Case Diagram
Shows system functionality from user perspective.
graph LR
User((User))
Admin((Admin))
User --> UC1[View Products]
User --> UC2[Add to Cart]
User --> UC3[Checkout]
Admin --> UC4[Manage Inventory]
Admin --> UC5[View Reports]
4. Activity Diagram
Shows workflow and business processes.
graph TD
Start([Start]) --> Input[Enter Credentials]
Input --> Validate{Valid?}
Validate -->|Yes| Success[Grant Access]
Validate -->|No| Retry{Attempts < 3?}
Retry -->|Yes| Input
Retry -->|No| Lock[Lock Account]
Success --> End([End])
Lock --> End
5. State Diagram
Shows object states and transitions.
stateDiagram-v2
[*] --> Draft
Draft --> Review : Submit
Review --> Approved : Approve
Review --> Rejected : Reject
Rejected --> Draft : Revise
Approved --> Published : Publish
Published --> [*]
6. Component Diagram
Shows system components and dependencies.
graph TD
UI[User Interface]
BL[Business Logic]
DAL[Data Access Layer]
DB[(Database)]
UI --> BL
BL --> DAL
DAL --> DB
Entity-Relationship (ER) Diagram for Databases
Shows the structure of a database, including entities (tables), attributes (columns), and relationships.
Database Schema Example
erDiagram
CUSTOMER ||--o{ ORDER : places
ORDER ||--|{ ORDER_ITEM : contains
PRODUCT ||--o{ ORDER_ITEM : "ordered in"
CATEGORY ||--o{ PRODUCT : has
CUSTOMER {
int customer_id PK
string name
string email
string phone
date created_at
}
ORDER {
int order_id PK
int customer_id FK
date order_date
decimal total_amount
string status
}
PRODUCT {
int product_id PK
int category_id FK
string name
decimal price
int stock_quantity
}
CATEGORY {
int category_id PK
string name
string description
}
ORDER_ITEM {
int order_item_id PK
int order_id FK
int product_id FK
int quantity
decimal unit_price
}
Cardinality Notation
Cardinality defines the numerical relationship between entities:
| Notation | Meaning | Example |
|---|---|---|
||--|| |
One to One (exactly one) | Person has one Passport |
||--o{ |
One to Many (one or more) | Customer places many Orders |
}o--o{ |
Many to Many | Students enroll in many Courses |
||--o| |
One to Zero or One | Person may have one Driver's License |
}o--|| |
Many to One | Many Employees work for one Department |
Visual Cardinality Examples
One-to-One: Each person has exactly one passport
erDiagram
PERSON ||--|| PASSPORT : has
PERSON {
int person_id PK
string name
}
PASSPORT {
int passport_id PK
int person_id FK
string passport_number
}
One-to-Many: One customer can place multiple orders
erDiagram
CUSTOMER ||--o{ ORDER : places
CUSTOMER {
int customer_id PK
string name
}
ORDER {
int order_id PK
int customer_id FK
date order_date
}
Many-to-Many: Students can enroll in many courses, courses have many students
erDiagram
STUDENT }o--o{ COURSE : enrolls
STUDENT {
int student_id PK
string name
}
COURSE {
int course_id PK
string course_name
}
ENROLLMENT {
int enrollment_id PK
int student_id FK
int course_id FK
date enrollment_date
}
STUDENT ||--o{ ENROLLMENT : has
COURSE ||--o{ ENROLLMENT : has
One-to-Zero-or-One: A person may or may not have a driver's license
erDiagram
PERSON ||--o| DRIVERS_LICENSE : "may have"
PERSON {
int person_id PK
string name
}
DRIVERS_LICENSE {
int license_id PK
int person_id FK
string license_number
}
Key Types
PK = Primary Key (unique identifier)
FK = Foreign Key (references another table)
UK = Unique Key (unique but not primary)
INDEX = Indexed column for faster queriesReal-World E-Commerce Database
erDiagram
USER ||--o{ CART : has
USER ||--o{ ORDER : places
USER ||--o{ REVIEW : writes
CART ||--|{ CART_ITEM : contains
PRODUCT ||--o{ CART_ITEM : "added to"
PRODUCT ||--o{ ORDER_ITEM : "ordered in"
PRODUCT ||--o{ REVIEW : receives
ORDER ||--|{ ORDER_ITEM : contains
USER {
int user_id PK
string username UK
string email UK
string password_hash
string address
datetime last_login
}
PRODUCT {
int product_id PK
string name
text description
decimal price
int stock
string image_url
}
CART {
int cart_id PK
int user_id FK
datetime created_at
datetime updated_at
}
ORDER {
int order_id PK
int user_id FK
decimal total
string status
datetime order_date
}
REVIEW {
int review_id PK
int user_id FK
int product_id FK
int rating
text comment
datetime created_at
}
Normalization Levels
| Normal Form | Rule | Purpose |
|---|---|---|
| 1NF | Atomic values, no repeating groups | Eliminate duplicate columns |
| 2NF | No partial dependencies | Remove redundant data |
| 3NF | No transitive dependencies | Ensure data depends only on primary key |
| BCNF | Every determinant is a candidate key | Stricter version of 3NF |
Common UML Relationships
Association: Class A -----> Class B (general relationship)
Aggregation: Class A <>----> Class B (has-a, weak ownership)
Composition: Class A <*>----> Class B (has-a, strong ownership)
Inheritance: Class A <|---- Class B (is-a relationship)
Dependency: Class A <....> Class B (uses temporarily)
Realization: Interface <|.... Class (implements)Best Practices
- Keep diagrams simple and focused
- Use appropriate diagram types for each purpose
- Include only relevant details
- Use consistent naming conventions
- Update diagrams as system evolves