Unified Modeling Language(UML)

Ba người ngồi họp, mỗi người vẽ một kiểu mũi tên, và không ai chắc mũi tên đứt nét của người kia nghĩa là gì. UML sinh ra để dẹp chuyện đó: một bộ ký hiệu chuẩn cho các sơ đồ mô tả hệ thống phần mềm, do OMG duy trì, hiện ở phiên bản 2.5.1 (ban hành cuối 2017, tới giờ vẫn là bản mới nhất). Nó không phải phương pháp làm việc, cũng không bắt bạn theo quy trình nào. Chỉ là bảng chữ cái.

Biết bốn tới năm loại sơ đồ UML là đủ cho phần lớn việc của BA. Học hết 14 loại chủ yếu để đi thi.

14 loại sơ đồ, BA thật sự dùng mấy loại

UML 2.5 chia hai nhóm: structure (cấu trúc — class, component, deployment, object, package...) và behavior (hành vi — use case, activity, sequence, state machine, communication...).

Đi làm ở VN, BA đụng nhiều nhất tới:

• Use case diagram — chốt phạm vi, ai làm được gì với hệ thống.
• Activity diagram — luồng nghiệp vụ có rẽ nhánh, có nhiều vai trò.
• Sequence diagram — thứ tự gọi giữa các hệ thống, cực hữu ích khi có tích hợp.
• State machine diagram — vòng đời một đối tượng nhiều trạng thái (đơn hàng, hồ sơ vay).
• Class diagram — thường dev vẽ, BA đọc và đối chiếu với nghiệp vụ.

Số còn lại là đất của kiến trúc sư và dev. Chưa vẽ component diagram bao giờ cũng không sao.

Ví dụ thực tế

Bản FS mình viết cho module cho vay tiêu dùng dày 74 trang, và tech lead đọc xong hỏi đúng một câu: sơ đồ đâu.

Bộ sơ đồ bổ sung sau đó có ba loại. Một use case diagram cho cả module, 11 use case. Một activity diagram cho luồng thẩm định, vì nó rẽ bốn nhánh theo điểm tín dụng. Ba sequence diagram cho ba tích hợp: CIC, eKYC và cổng giải ngân. Class diagram thì dev tự vẽ bên tài liệu kỹ thuật, mình chỉ review xem có thiếu trường nào so với data dictionary không. Bộ đó đủ để cả team không cãi nhau suốt năm tháng.

Lỗi hay gặp

• Vẽ đúng cú pháp nhưng sai người đọc. Đưa sequence diagram cho trưởng phòng nghiệp vụ thì họ nhìn như nhìn bản vẽ mạch điện.
• Nhồi mọi thứ vào một sơ đồ. Một sơ đồ trả lời một câu hỏi. Quá 15–20 phần tử là nên tách.
• Dùng sai <<include>> và <<extend>>. Include là luôn xảy ra, extend là có điều kiện — và hướng mũi tên cũng ngược nhau: include vẽ từ use case gốc trỏ sang use case con, extend vẽ từ use case phụ trỏ ngược về use case gốc. Rất nhiều tài liệu ở VN dùng ngược hai cái này. Lỗi tồn tại được vì sơ đồ include/extend hiếm khi bị ai soi tới mức đó — cho đến lúc có người vẽ lại theo tài liệu và ra một luồng khác hẳn.
• Vẽ xong rồi bỏ đó. Sơ đồ lệch với hệ thống thật còn tệ hơn không có sơ đồ, vì dev mới vào tin nó.

Mẹo khi đi làm

Đừng học UML theo kiểu cày hết 14 loại. Học đúng loại cần cho tài liệu sắp viết, vẽ thật, để dev bắt lỗi, rồi mới sang loại tiếp theo. Nhớ nhanh hơn nhiều.

Chuẩn UML để ngỏ khá nhiều chỗ, nên nếu công ty đã có template riêng thì theo template. Điều đáng giữ là cả team đọc giống nhau. Mình từng mất một buổi tranh luận với QC về đầu mũi tên rỗng hay đặc, trong khi thứ cần chốt là hệ thống gọi đồng bộ hay bất đồng bộ. Ghi một dòng chú thích cạnh mũi tên là xong.

Còn nếu phải chọn giữa vẽ UML đẹp và viết acceptance criteria rõ ràng: chọn cái sau.