Class Diagram
Sơ đồ UML mô tả các lớp đối tượng trong thiết kế hướng đối tượng: thuộc tính, hành vi và quan hệ giữa chúng. Dev vẽ là chính, nhưng BA cần đọc được để soi quy tắc nghiệp vụ.
Định nghĩa
Sơ đồ này của dev. Nói thẳng vậy cho nhanh. Nhưng BA vẫn nên đọc được, vì đây là chỗ dev để lộ họ hiểu nghiệp vụ của bạn tới đâu, và là chỗ các quy tắc nghiệp vụ bị chôn vào code nếu không ai để ý.
Class diagram mô tả các lớp đối tượng trong thiết kế hướng đối tượng: dữ liệu chúng giữ, việc chúng làm, và cách chúng liên hệ với nhau.
Đọc một hộp class
Mỗi class là một hộp ba tầng: tên lớp, danh sách thuộc tính, danh sách phương thức. Dấu đứng trước cho biết phạm vi truy cập: + public, - private, # protected.
Các đường nối cần phân biệt:
- Association: đường thẳng, hai lớp biết nhau.
- Aggregation (hình thoi rỗng): quan hệ "có" lỏng, phần tử con sống độc lập được.
- Composition (hình thoi đặc): xoá cha là con chết theo. Ví dụ dòng chi tiết đơn hàng không tồn tại nếu không có đơn hàng.
- Generalization (tam giác rỗng): kế thừa.
- Multiplicity:
1,0..1,1..*,*ghi ở hai đầu đường nối.
So sánh với ERD
Đây là cặp bị nhầm nhiều nhất, kể cả trong tài liệu đã qua review.
| ERD | Class diagram | |
|---|---|---|
| Mô hình hoá cái gì | Dữ liệu được lưu trong CSDL | Đối tượng trong thiết kế phần mềm |
| Thành phần | Entity, thuộc tính, khoá chính, khoá ngoại | Class, thuộc tính, phương thức |
| Có hành vi không | Không | Có, đó là phần method |
| Quan hệ | 1-1, 1-n, n-n vẽ bằng chân quạ | Association, aggregation, composition, kế thừa |
| Ánh xạ | Một entity thường thành một bảng | Có class chẳng có bảng nào tương ứng |
| Ai vẽ, ai đọc | BA và DBA vẽ, cả team đọc | Dev và kiến trúc sư vẽ, BA đọc |
Chỗ dễ nhớ nhất: lớp PaymentValidator chỉ chứa quy tắc, không lưu gì cả, nhưng vẫn tồn tại trong class diagram. Ngược lại, bảng trung gian của quan hệ n-n trong ERD thường chẳng thành lớp riêng nào.
Ví dụ thực tế
Giữa buổi review thiết kế, mình khựng lại ở một lớp tên ContractRenewalPolicy. Nó không ứng với bảng nào trong ERD.
Module đang làm là quản lý hợp đồng thuê mặt bằng cho một chuỗi F&B, 117 điểm bán. ERD có contract, contract_term, store, payment_schedule. Lớp kia không lưu gì cả, chỉ chứa quy tắc gia hạn: báo trước 90 ngày, tăng 8 phần trăm mỗi kỳ nếu điều khoản ghi rõ.
Mức tăng 8 phần trăm bị đặt cứng ngay trong lớp đó, trong khi hợp đồng thật có ba mức khác nhau tuỳ chủ nhà. Sửa lúc ấy mất nửa ngày. Sửa sau khi 117 hợp đồng đã chạy thật thì là chuyện khác hẳn.
BA đọc class diagram để làm gì
- Đối chiếu với data dictionary: có trường nào thiếu, kiểu dữ liệu nào sai, có trường nghiệp vụ nào bị bỏ quên.
- Tìm xem quy tắc nghiệp vụ nằm ở đâu. Quy tắc hay thay đổi mà bị chôn cứng trong lớp là rủi ro cho các CR sau này.
- Ước lượng tác động khi khách đổi yêu cầu: nhìn số đường nối vào một lớp là đoán được sửa nó đụng tới bao nhiêu chỗ.
Không cần vẽ. Chỉ cần lúc review thiết kế, chỉ vào một lớp và hỏi "cái quy tắc này lấy từ đâu ra".
