Biểu đồ lớp UML và mô hình hóa đối tượng

1. Tổng quan

A. Định nghĩa

Biểu đồ lớp (Class Diagram) là biểu đồ cấu trúc (tĩnh) tiêu biểu của UML, biểu diễn các lớp cấu thành hệ thống cùng thuộc tính (attribute)·thao tác (operation) của chúng, và quan hệ giữa các lớp (liên kết·kết tập·hợp thành·tổng quát hóa·phụ thuộc); nó là sản phẩm cuối cùng của phân tích·thiết kế hướng đối tượng (OOAD) và là bản thiết kế dẫn tới mã nguồn.

Lý do biểu đồ lớp nằm ở trung tâm thiết kế hướng đối tượng là vì nó "gói khung xương (cấu trúc) của hệ thống vào một trang". Các biểu đồ của UML biểu diễn những góc nhìn khác nhau. Nếu biểu đồ use case cho thấy 'làm gì (yêu cầu·phạm vi chức năng)', biểu đồ tuần tự·cộng tác cho thấy 'chảy như thế nào (tương tác động)', thì biểu đồ lớp cho thấy 'được cấu thành từ gì (cấu trúc tĩnh)'. Phát triển hướng đối tượng được tinh chỉnh dần khi đi qua lại giữa ba góc nhìn này, và điểm hội tụ của chúng chính là biểu đồ lớp.

Luồng điển hình của phân tích·thiết kế hướng đối tượng như sau. Trước hết, rút ra các khái niệm cốt lõi (danh từ) từ miền bài toán (domain) để tạo mô hình đối tượng khái niệm (mô hình miền), rồi cụ thể hóa tương tác theo từng kịch bản bằng biểu đồ tuần tự. Khi đó, các thông điệp mà đối tượng trao đổi được nâng lên thành phương thức (thao tác) của đối tượng nhận. Cuối cùng, tổng hợp chúng lại để hoàn thiện thành biểu đồ lớp với thuộc tính·thao tác·quan hệ được xác định. Ví dụ với hiệu sách trực tuyến, 'thành viên·sách·đơn hàng·giỏ hàng' trở thành đối tượng khái niệm, các tương tác "đặt hàng·thanh toán·trừ tồn kho" trở thành phương thức, và quan hệ giữa chúng (một đơn hàng có nhiều dòng đơn hàng, thành viên đặt nhiều đơn hàng) được sắp xếp thành liên kết·bội số của biểu đồ lớp. Tức là biểu đồ lớp là điểm hội tụ cuối cùng của hoạt động phân tích·thiết kế, và là mắt xích nối hiện thực với tài liệu.

B. Bối cảnh ra đời và sự cần thiết

Thời kỳ phương pháp luận cấu trúc, dữ liệu (ERD) và chức năng (DFD) được mô hình hóa tách rời, nhưng dữ liệu và hành vi (thao tác) xử lý dữ liệu đó vận hành riêng rẽ nên dễ tổn thương khi thay đổi. Hướng đối tượng giải quyết vấn đề này bằng cách đóng gói dữ liệu và thao tác vào một đối tượng (lớp), và thứ chuẩn hóa trực quan cấu trúc đó chính là biểu đồ lớp UML. UML là sự hợp nhất các phương pháp luận của Booch·Rumbaugh (OMT)·Jacobson (OOSE) và được OMG chuẩn hóa (hiện là UML 2.x); trong đó biểu đồ lớp là biểu đồ thực tiễn nhất, gắn trực tiếp với sinh mã·kỹ nghệ ngược (Reverse Engineering). Hệ thống càng phức tạp càng cần ngôn ngữ chung để chia sẻ·kiểm chứng cấu trúc, và biểu đồ lớp là phương tiện giao tiếp thiết yếu để nhà phát triển·nhà thiết kế·bên liên quan thống nhất về cấu trúc.

C. Khái quát luồng mô hình hóa

flowchart LR
  U["Use case<br/>(yêu cầu·phạm vi chức năng)"] --> O["Mô hình đối tượng khái niệm<br/>(khái niệm cốt lõi của miền)"]
  O --> S["Tuần tự<br/>(tương tác→rút ra phương thức)"]
  S --> C["Biểu đồ lớp<br/>(xác định thuộc tính·thao tác·quan hệ)"]
  C --> Code["Mã nguồn<br/>(sinh thuận/kỹ nghệ ngược)"]
  style C fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px

2. Các thành phần của biểu đồ lớp

A. Biểu diễn lớp và tính khả kiến

Lớp được vẽ bằng hình chữ nhật chia ba ngăn. Ngăn trên cùng ghi tên lớp, ngăn giữa ghi thuộc tính, ngăn dưới ghi thao tác (operation). Trước thuộc tính và thao tác gắn ký hiệu tính khả kiến (visibility) để nêu rõ phạm vi truy cập. + là public (công khai ra ngoài), - là private (chỉ bên trong lớp của mình), # là protected (cho phép truy cập trong quan hệ kế thừa), ~ là package (bên trong cùng package). Ví dụ, - balance : int nghĩa là số dư là thuộc tính ẩn không thể truy cập trực tiếp từ bên ngoài, còn + withdraw(amount : int) : boolean là thao tác rút tiền mà bên ngoài có thể gọi. Tính khả kiến không đơn thuần là ký pháp mà là cơ chế cưỡng chế nguyên tắc hướng đối tượng đóng gói·che giấu thông tin ở cấp biểu đồ. Nếu giấu thuộc tính ở private và chỉ cho truy cập qua phương thức public, dù hiện thực bên trong thay đổi thì hợp đồng bên ngoài (giao diện) vẫn được giữ, làm giảm lan truyền thay đổi.

B. Các loại quan hệ (Relationship) và ý nghĩa

Sức biểu đạt thực sự của biểu đồ lớp nằm ở quan hệ giữa các lớp. Quan hệ được chia thành nhiều loại theo độ mạnh và ý nghĩa của sự kết dính, và việc chọn quan hệ nào quyết định chất lượng thiết kế.

Liên kết (Association) là quan hệ hai lớp được nối về mặt cấu trúc, biết và tham chiếu lẫn nhau; vẽ bằng nét liền và ghi bội số (multiplicity, ví dụ: 1, 0..1, 1..*, *) ở hai đầu. Ví dụ, "1 thành viên đặt từ 0 đơn hàng trở lên" được biểu diễn là thành viên 1 — đơn hàng 0..*. Có thể dùng mũi tên hướng (navigability) để nêu rõ bên nào tham chiếu bên nào.

Kết tập (Aggregation) và hợp thành (Composition) đều là quan hệ 'toàn thể-bộ phận (whole-part, has-a)' nhưng độ mạnh kết dính khác nhau. Kết tập (hình thoi rỗng) là sở hữu lỏng trong đó bộ phận có thể tồn tại độc lập với toàn thể (ví dụ: phòng ban và nhân viên — phòng ban mất đi thì nhân viên vẫn tồn tại), còn hợp thành (hình thoi đặc) là sở hữu mạnh trong đó bộ phận phụ thuộc vòng đời của toàn thể (ví dụ: đơn hàng và dòng đơn hàng — xóa đơn hàng thì dòng đơn hàng cũng bị hủy theo). Khác biệt tinh tế này quyết định trách nhiệm tạo·hủy đối tượng và cách quản lý tham chiếu trong hiện thực.

Tổng quát hóa (Generalization) là quan hệ kế thừa (is-a), vẽ mũi tên tam giác rỗng hướng về lớp cha (cấp trên). Lớp con thừa hưởng thuộc tính·thao tác của lớp cha và đặc thù hóa (ví dụ: 'thanh toán' là cha, 'thanh toán thẻ·chuyển khoản·thanh toán nhanh' là con). Hiện thực hóa (Realization) là quan hệ giữa interface và lớp hiện thực (nét đứt+tam giác), còn phụ thuộc (Dependency) là quan hệ yếu trong đó một lớp sử dụng tạm thời lớp khác (dưới dạng tham số·biến cục bộ) (mũi tên nét đứt).

C. Biểu đồ ví dụ về cấu trúc

Dưới đây là cấu trúc lớp rút gọn của miền hiệu sách trực tuyến, ví dụ thể hiện cùng lúc liên kết·bội số·hợp thành·tổng quát hóa.

classDiagram
  class Member {
    -memberId : String
    -name : String
    +placeOrder() Order
  }
  class Order {
    -orderId : String
    -orderDate : Date
    +calcTotal() int
  }
  class OrderItem {
    -quantity : int
    +subtotal() int
  }
  class Book {
    -isbn : String
    -price : int
  }
  class Payment {
    +pay(amount) boolean
  }
  class CardPayment {
    +pay(amount) boolean
  }
  Member "1" --> "0..*" Order : places
  Order "1" *-- "1..*" OrderItem : contains
  OrderItem "*" --> "1" Book : refers
  Payment <|-- CardPayment
  Order "1" --> "1" Payment : uses

Biểu đồ này truyền đạt cấu trúc cô đọng hơn nhiều so với đặc tả văn bản. Hình thoi đặc (*--) nối Order và OrderItem cho thấy ngay đó là hợp thành — đơn hàng mất đi thì dòng đơn hàng cũng mất theo, còn tam giác (<|--) nối Payment và CardPayment cho thấy thanh toán thẻ là một loại thanh toán.

3. Liên kết với mô hình đối tượng khái niệm·biểu đồ tuần tự

Mô hình đối tượng khái niệm (mô hình miền) là giai đoạn trước thiết kế, chỉ xác định các khái niệm cốt lõi (đối tượng miền) của miền bài toán và quan hệ giữa chúng. Ở giai đoạn này chưa xác định chi tiết hiện thực (chữ ký phương thức·tính khả kiến·kiểu dữ liệu), mà chỉ vẽ "miền này có những khái niệm nào và chúng đan xen với nhau ra sao". Nhờ vậy dễ giao tiếp với bên liên quan bằng ngôn ngữ miền (ngôn ngữ phổ quát — ubiquitous language), và có thể tập trung vào bản chất vấn đề mà không bị thiên lệch kỹ thuật.

Tiếp theo, khi định nghĩa thông điệp giữa các đối tượng theo một kịch bản cụ thể trong biểu đồ tuần tự, thông điệp đó được nâng lên thành thao tác (phương thức) của đối tượng nhận. Ví dụ, nếu thiết kế "đối tượng đơn hàng gửi thông điệp pay(amount) tới đối tượng thanh toán" thì lớp thanh toán sẽ có thao tác pay(amount). Như vậy thiết kế được tinh chỉnh bằng cách phản ánh các thao tác rút ra từ mô hình động (tuần tự) vào mô hình tĩnh (lớp), và ngược lại cấu trúc lớp kiểm chứng tính khả thi của tuần tự. Hai mô hình tuần hoàn bổ sung cho nhau và hội tụ. [[uml-sequence]]

Điều quan trọng nhất trong sự liên kết này là phân công trách nhiệm (Responsibility Assignment). Nếu quyết định tốt đối tượng nào xử lý thông điệp nào (tức đặt phương thức ở lớp nào) thì thiết kế có độ gắn kết cao và độ kết dính thấp; nếu quyết định sai sẽ sinh ra 'God Class' dồn trách nhiệm vào một lớp cụ thể. Hệ thống hóa các nguyên tắc này là mẫu GRASP (Information Expert, Creator, Controller v.v.), và biểu đồ lớp là chiếc bình chứa kết quả đó.

4. Chuyên sâu — Liên kết mẫu thiết kế·mã nguồn và áp dụng thực tế

Biểu đồ lớp còn được dùng như ngôn ngữ chuẩn để biểu diễn và trao đổi về mẫu thiết kế. Các mẫu thiết kế GoF (strategy·observer·factory·decorator v.v.) đều được định nghĩa cấu trúc bằng biểu đồ lớp; ví dụ mẫu Strategy được biểu diễn bằng cấu trúc Context phụ thuộc vào interface Strategy và các chiến lược cụ thể hiện thực hóa nó. Nhờ vậy có thể thống nhất ý đồ thiết kế "hãy tách phương thức thanh toán bằng mẫu strategy" chỉ bằng một trang biểu đồ.

Trong thực tế, biểu đồ lớp được nối hai chiều với mã thông qua kỹ nghệ thuận (Forward Engineering) và kỹ nghệ ngược (Reverse Engineering). Các công cụ như Enterprise Architect, Visual Paradigm, plugin UML của IntelliJ/Eclipse tự động sinh mã khung lớp từ biểu đồ lớp (thuận), hoặc trích cấu trúc lớp từ mã nguồn kế thừa để trực quan hóa thành biểu đồ (ngược). Cách sau đặc biệt hữu ích khi tìm hiểu hệ thống kế thừa có tài liệu nghèo nàn hoặc phân tích mức ảnh hưởng bảo trì. Gần đây, khi văn hóa ưu tiên mã (Code-First) lan rộng, cách viết biểu đồ bằng văn bản như PlantUML·Mermaid thay cho công cụ CASE nặng nề và quản lý phiên bản trong kho mã (diagram-as-code) đang tăng lên. Điều này giúp tài liệu thiết kế tiến hóa cùng với mã, giảm vấn đề 'tài liệu-hiện thực không khớp'. Tuy nhiên, với hệ thống có miền phức tạp, mẹo thực tế là thay vì cố nhồi mọi thứ vào một biểu đồ lớp, hãy chia theo đơn vị bounded context của thiết kế hướng miền (DDD) để duy trì mô hình có độ gắn kết cao.

5. Các điểm cần cân nhắc và hàm ý (góc nhìn Kỹ sư chuyên nghiệp)

1. Duy trì tính nhất quán (Consistency) giữa các mô hình: Use case→đối tượng khái niệm→tuần tự→lớp phải được nối nhất quán. Đặc biệt nếu thông điệp của tuần tự và thao tác của lớp, quan hệ của mô hình khái niệm và liên kết của lớp lệch nhau thì độ tin cậy thiết kế sụp đổ. Phải liên tục kiểm chứng tính nhất quán bằng kiểm tra nhất quán mô hình (consistency check) của công cụ CASE hoặc review diagram-as-code.

2. Mức trừu tượng phù hợp và chi tiết hóa tiến hóa: Lớp ở giai đoạn phân tích được giữ đơn giản, lấy miền làm trung tâm, và ở giai đoạn thiết kế dần bổ sung tính khả kiến·kiểu dữ liệu·chi tiết hiện thực. Nếu quá chi tiết ngay từ đầu, chi phí duy trì·sửa đổi khi yêu cầu thay đổi sẽ tăng vọt. Tinh luyện theo từng bước 'lớp phân tích → lớp thiết kế → lớp hiện thực' là đáng mong muốn.

3. Đánh đổi giữa độ kết dính·độ gắn kết và lựa chọn quan hệ: Dùng kết tập/hợp thành/tổng quát hóa/phụ thuộc nào quyết định độ mạnh kết dính. Kế thừa (tổng quát hóa) cho khả năng tái sử dụng mạnh nhưng thay đổi ở lớp cha lan xuống toàn bộ lớp con, nên theo nguyên tắc "ưu tiên hợp thành hơn kế thừa (Favor composition over inheritance)", cần phán đoán dùng hợp thành·interface để giảm kết dính ở nơi cần linh hoạt.

4. Sinh mã·kỹ nghệ ngược và tính nhất quán tài liệu-hiện thực: Biểu đồ lớp có thể chuyển đổi hai chiều với mã nên có thế mạnh trong duy trì nhất quán thiết kế-hiện thực và tìm hiểu hệ thống kế thừa. Tuy nhiên, mã sinh tự động chỉ cung cấp khung nên không được tin mù quáng, và chiến lược vận hành đặt biểu đồ trong kho bằng diagram-as-code (Mermaid/PlantUML) để tiến hóa cùng mã là hữu hiệu.

5. Phân chia mô hình trong miền quy mô lớn: Khi hệ thống lớn lên, một biểu đồ lớp duy nhất mất khả năng đọc. Phải chia theo đơn vị package·hệ thống con, và áp dụng khái niệm bounded context·aggregate của DDD để thiết lập ranh giới mô hình có độ gắn kết cao thì mới bảo đảm được khả năng bảo trì và mở rộng.

Tài liệu tham khảo

• OMG, đặc tả Unified Modeling Language (UML) 2.5.1: https://www.omg.org/spec/UML/
• IBM Developer, "UML basics: The class diagram": https://developer.ibm.com/articles/the-class-diagram/
• Mermaid, tài liệu Class diagram: https://mermaid.js.org/syntax/classDiagram.html
• Refactoring Guru, mẫu thiết kế GoF (biểu đồ cấu trúc): https://refactoring.guru/design-patterns

Tóm tắt một câu: Biểu đồ lớp là mô hình tĩnh UML biểu diễn lớp cùng thuộc tính·thao tác và các quan hệ liên kết·kết tập·hợp thành·tổng quát hóa·phụ thuộc, là điểm hội tụ của thiết kế hướng đối tượng đi từ mô hình đối tượng khái niệm→tuần tự (thông điệp→phương thức)→lớp và là bản thiết kế nối hai chiều với mã; tính nhất quán giữa các mô hình·mức trừu tượng phù hợp·lựa chọn quan hệ (độ kết dính) là cốt lõi của chất lượng thiết kế.