Phân tích thiết kế hệ thống thông tin quản lý

Bài 17. Class Diagram – Từ mô hình nghiệp vụ đến thiết kế phần mềm

“Domain Model phản ánh thế giới thực. Class Diagram phản ánh cách phần mềm được xây dựng để mô phỏng thế giới đó.”

Theo tôi, Bài 17 là bài cuối cùng của pha “Phân tích” và là bài đầu tiên của pha “Thiết kế”.

Đây là nơi rất nhiều sinh viên bắt đầu bị lẫn lộn.

Các em thường nghĩ:

Domain Model = Class Diagram

Thậm chí nhiều sách còn dùng hai khái niệm này gần như thay thế cho nhau.

Đó là cách hiểu chưa chính xác.

Nếu Domain Model trả lời:

Hệ thống đang quản lý những khái niệm nào?

thì Class Diagram trả lời:

Phần mềm sẽ được tổ chức thành các lớp như thế nào?

Đây là hai góc nhìn khác nhau.

Chính vì vậy, Bài 17 cần giúp sinh viên chuyển đổi tư duy từ Business sang Software.

Vị trí của bài học trong chuỗi bài

Business Problem
        ↓
Stakeholder
        ↓
Requirement
        ↓
Use Case
        ↓
Activity Diagram
        ↓
Sequence Diagram
        ↓
Domain Model
        ↓
Class Diagram   ← Bạn đang ở đây
        ↓
Database Design
        ↓
Implementation

Mục tiêu bài học

Sau khi hoàn thành bài học này, bạn có thể:

  • Hiểu vai trò của Class Diagram trong thiết kế phần mềm.
  • Phân biệt Domain Model và Class Diagram.
  • Xây dựng Class Diagram từ Domain Model.
  • Hiểu các loại quan hệ giữa các lớp.
  • Tránh các sai lầm phổ biến khi thiết kế lớp.

1. Vì sao cần Class Diagram?

Sau bài trước, chúng ta đã có Domain Model.

Ví dụ.

Hệ thống quản lý đào tạo có các Entity:

  • Sinh viên
  • Học phần
  • Lớp học phần
  • Giảng viên
  • Đăng ký học phần

Đây mới chỉ là mô hình nghiệp vụ.

Nếu là lập trình viên, câu hỏi sẽ là:

  • Mỗi Entity sẽ trở thành lớp nào?
  • Thuộc tính nào cần lưu trữ?
  • Hành vi nào thuộc về lớp đó?
  • Các lớp liên kết với nhau như thế nào?

Đó là vai trò của Class Diagram.

2. Class Diagram là gì?

Class Diagram là sơ đồ UML mô tả cấu trúc tĩnh của hệ thống phần mềm.

Một Class Diagram thường thể hiện:

  • Các lớp (Class).
  • Thuộc tính (Attribute).
  • Phương thức (Operation).
  • Quan hệ giữa các lớp.

Nếu Domain Model là bản đồ của nghiệp vụ, thì Class Diagram là bản thiết kế của phần mềm.

3. Từ Entity đến Class

Không phải mọi Domain Entity đều trở thành Class theo cách một-một.

Ví dụ:

Domain Entity:

Sinh viên

Có thể trở thành:

Student
-------------------
studentId
fullName
email
dateOfBirth
-------------------
registerCourse()
dropCourse()
updateProfile()

Ở đây, lớp không chỉ có dữ liệu mà còn có hành vi.

Đó là điểm khác biệt quan trọng.

4. Thành phần của một Class

Một lớp thường gồm ba phần.

Tên lớp

Nên là danh từ.

Ví dụ:

  • Student
  • Course
  • Lecturer
  • Enrollment

Không nên dùng động từ.

Thuộc tính (Attribute)

Mô tả trạng thái của đối tượng.

Ví dụ:

Student

  • studentId
  • fullName
  • email

Thuộc tính nên phản ánh thông tin mà đối tượng cần quản lý.

Phương thức (Operation)

Mô tả hành vi của đối tượng.

Ví dụ:

Student

  • registerCourse()
  • cancelRegistration()
  • updateProfile()

Đây là điểm mà Domain Model chưa đề cập.

5. Quan hệ giữa các lớp

Association

Quan hệ cộng tác.

Ví dụ:

Student —— Enrollment

Student biết đến Enrollment.

Aggregation

Quan hệ “bao gồm”, nhưng các thành phần có thể tồn tại độc lập.

Ví dụ:

Department ◇── Lecturer

Giảng viên vẫn tồn tại nếu khoa thay đổi.

Composition

Quan hệ sở hữu chặt chẽ.

Ví dụ:

Order ◆── OrderItem

Nếu đơn hàng bị xóa.

Các dòng chi tiết cũng không còn ý nghĩa.

Generalization

Quan hệ kế thừa.

Ví dụ:

User
↑
Student
↑
Lecturer

Student và Lecturer kế thừa các thuộc tính chung của User.

6. Từ Sequence Diagram đến Class Diagram

Sequence Diagram giúp chúng ta phát hiện trách nhiệm của từng lớp.

Ví dụ.

Nếu Sequence Diagram cho thấy:

RegistrationService

  • kiểm tra điều kiện
  • lưu đăng ký
  • gửi thông báo

Có thể đặt câu hỏi:

RegistrationService đang làm quá nhiều việc?

Có nên tách thành:

  • RegistrationService
  • ValidationService
  • NotificationService

Như vậy, Sequence Diagram không chỉ mô tả tương tác mà còn hỗ trợ hoàn thiện Class Diagram.

7. Thiết kế lớp theo nguyên tắc trách nhiệm đơn

Một lớp nên có một lý do chính để thay đổi.

Ví dụ không tốt:

Student

  • quản lý thông tin sinh viên
  • gửi email
  • xuất báo cáo
  • tính học phí

Lớp này đang gánh quá nhiều trách nhiệm.

Nên tách thành các lớp chuyên biệt.

Đây là tinh thần của Single Responsibility Principle (SRP).

Sai lầm thường gặp

Biến Domain Model thành Class Diagram

Nhiều sinh viên chỉ thêm các phương thức get() và set() vào Domain Model rồi gọi đó là Class Diagram.

Điều này chưa phản ánh thiết kế.

Class Diagram cần thể hiện cả hành vi và quan hệ của các lớp.

Đưa mọi bảng dữ liệu thành Class

Class không phải là bản sao của bảng cơ sở dữ liệu.

Một lớp được tạo ra để thực hiện trách nhiệm trong phần mềm, không chỉ để lưu dữ liệu.

Thiết kế lớp quá lớn

Một lớp có hàng chục thuộc tính và hàng chục phương thức thường là dấu hiệu của thiết kế chưa tốt.

Hãy xem xét phân tách trách nhiệm.

Thiếu nhất quán với Domain Model

Nếu Class Diagram xuất hiện các lớp mà Domain Model chưa từng đề cập, cần xem lại:

  • Đó là lớp nghiệp vụ hay lớp kỹ thuật?
  • Có thực sự cần thiết không?

Tóm tắt

Class Diagram là mô hình thiết kế mô tả:

  • Các lớp trong hệ thống.
  • Dữ liệu mà mỗi lớp quản lý.
  • Hành vi mà mỗi lớp thực hiện.
  • Quan hệ giữa các lớp.

Đây là cầu nối giữa phân tích và lập trình.

Hãy nhớ:

Một Class không chỉ lưu dữ liệu. Một Class phải chịu trách nhiệm cho một phần hành vi của hệ thống.

Deliverable

Từ Domain Model đã xây dựng:

  1. Chuyển các Entity thành các Class phù hợp.
  2. Xác định thuộc tính và phương thức chính của mỗi Class.
  3. Xác định các quan hệ giữa các Class.
  4. Kiểm tra lại bằng các câu hỏi:
  • Mỗi Class có một trách nhiệm chính không?
  • Hành vi đã được đặt đúng Class chưa?
  • Có lớp nào đang ôm quá nhiều trách nhiệm không?

Checklist

Sau khi học xong bài này, bạn nên trả lời được:

  • Class Diagram dùng để làm gì?
  • Phân biệt Domain Model và Class Diagram.
  • Biết xác định Attribute và Operation.
  • Hiểu các quan hệ Association, Aggregation, Composition và Generalization.
  • Thiết kế được Class Diagram phù hợp với Requirement và Domain Model.

Góc nhìn nghề nghiệp

Trong nhiều dự án hiện đại, Class Diagram không còn được cập nhật đầy đủ sau mỗi lần thay đổi mã nguồn. Tuy nhiên, tư duy thiết kế lớp vẫn là kỹ năng cốt lõi của một kỹ sư phần mềm. Một lập trình viên giỏi không chỉ biết viết mã, mà còn biết phân chia trách nhiệm, giảm phụ thuộc giữa các lớp và thiết kế mô hình dễ mở rộng, dễ bảo trì.

Vì vậy, giá trị của Class Diagram không nằm ở bản thân sơ đồ, mà ở quá trình tư duy thiết kế. Một sơ đồ đơn giản nhưng phản ánh đúng trách nhiệm và mối quan hệ giữa các lớp sẽ hữu ích hơn nhiều so với một sơ đồ phức tạp nhưng chỉ sao chép cấu trúc cơ sở dữ liệu.

Kết thúc một chặng đường

Đến Bài 17, chúng ta đã hoàn thành gần như toàn bộ pha Phân tích và Thiết kế hệ thống:

  • Xác định vấn đề và mục tiêu kinh doanh.
  • Phân tích stakeholder.
  • Mô hình hóa quy trình AS-IS và TO-BE.
  • Khai thác, phân loại và đánh giá Requirement.
  • Xây dựng Use Case và các mô hình hành vi.
  • Mô hình hóa miền nghiệp vụ.
  • Thiết kế cấu trúc lớp.

Đây là một chuỗi tư duy xuyên suốt: từ nhu cầu của tổ chức đến mô hình của phần mềm.

Định hướng học phần tiếp theo

Thay vì kết thúc ở UML như nhiều giáo trình truyền thống, ta sẽ mở rộng series sang giai đoạn hiện thực hóa thiết kế, bao gồm:

  1. Thiết kế cơ sở dữ liệu từ Domain Model và Class Diagram.
  2. Kiến trúc phần mềm (Layered Architecture, Clean Architecture, Microservices ở mức giới thiệu).
  3. Thiết kế API và hợp đồng dịch vụ.
  4. Quản lý thay đổi Requirement và truy vết tác động.
  5. Từ mô hình đến mã nguồn: cách UML hỗ trợ lập trình, thay vì tồn tại như các tài liệu độc lập.

Điều này giúp chuỗi bài này không chỉ dừng ở môn học Phân tích và Thiết kế Hệ thống Thông tin, mà còn trở thành nền tảng cho các học phần như Lập trình hướng đối tượng, Kiến trúc phần mềm, Thiết kế cơ sở dữ liệu và Đồ án phát triển phần mềm. Đây cũng chính là mục tiêu của một chuỗi bài mang tính “kim chỉ nam”: giúp sinh viên xây dựng một tư duy nhất quán, thay vì học từng môn như những mảnh ghép rời rạc.

Comments are closed.

MENU