Vẽ sơ đồ use case, ERD và sơ đồ tuần tự cho đồ án trong một buổi

Chương phân tích thiết kế là chương được chấm kỹ nhất trong báo cáo, và cũng là chương nhiều bạn mất ba ngày vì loay hoay với công cụ vẽ. Làm đúng thứ tự thì một buổi là xong.

Thứ tự đúng: danh sách yêu cầu → use case → ERD → sơ đồ lớp → sơ đồ tuần tự. Vẽ ngược thứ tự này là phải vẽ lại.

Công cụ nên dùng

draw.io (nay là diagrams.net) — miễn phí, chạy trong trình duyệt, có sẵn khuôn UML và ERD, xuất ảnh PNG nền trắng để dán vào Word. Đây là lựa chọn mặc định cho đồ án.

Mermaid — viết sơ đồ bằng chữ, hợp nếu bạn ngại kéo thả. Nhược điểm là khó chỉnh bố cục cho đẹp.

MySQL Workbench — dùng riêng cho ERD. Ưu điểm lớn: vẽ xong xuất thẳng ra câu lệnh tạo bảng, và ngược lại nếu đã có cơ sở dữ liệu thì hút ngược ra sơ đồ. Ai code trước rồi mới viết báo cáo nên dùng cách này.

Đừng vẽ bằng Word SmartArt. Sửa một lần là vỡ bố cục.

Bước 1: Danh sách yêu cầu chức năng

Trước khi vẽ, viết ra bảng hai cột: vai trò và việc họ làm được. Ví dụ hệ bán hàng:

• Khách: xem sản phẩm, tìm kiếm, thêm giỏ hàng, đặt hàng, xem đơn của mình
• Nhân viên: xử lý đơn, cập nhật trạng thái, quản lý tồn kho
• Quản trị: quản lý sản phẩm, quản lý tài khoản, xem báo cáo doanh thu

Bảng này chính là bản nháp của sơ đồ use case. Có nó rồi thì vẽ chỉ là chép lại.

Bước 2: Sơ đồ use case

Tác nhân vẽ hình người, use case vẽ hình bầu dục, đường thẳng nối tác nhân với use case họ dùng được.

Ba lỗi bị bắt nhiều nhất:

Đặt tên use case bằng danh từ. Use case là hành động, phải là động từ: "Đặt hàng", không phải "Đơn hàng". "Quản lý sản phẩm", không phải "Sản phẩm".

Dùng sai include và extend. include là bước bắt buộc luôn xảy ra: "Đặt hàng" include "Đăng nhập". extend là nhánh chỉ xảy ra trong một số trường hợp: "Đặt hàng" được extend bởi "Áp mã giảm giá". Không chắc thì đừng vẽ mũi tên nào cả, thiếu ít điểm hơn là vẽ sai.

Vẽ quá chi tiết. Không cần use case cho từng nút bấm. Mười đến mười lăm use case cho một đồ án là hợp lý.

Sau sơ đồ, viết đặc tả cho ba đến năm use case chính, mỗi cái một bảng: tác nhân, tiền điều kiện, luồng chính từng bước, luồng thay thế, hậu điều kiện. Chỉ đặc tả use case quan trọng, không đặc tả hết.

Bước 3: Sơ đồ quan hệ thực thể

Bắt đầu bằng cách gạch chân mọi danh từ trong danh sách yêu cầu: sản phẩm, danh mục, khách hàng, đơn hàng, nhân viên. Đó là các thực thể.

Với mỗi cặp thực thể, hỏi đúng một câu theo cả hai chiều: một cái này có nhiều cái kia không?

• Một danh mục có nhiều sản phẩm; một sản phẩm thuộc một danh mục → một-nhiều, đặt khoá ngoại danh_muc_id ở bảng sản phẩm
• Một đơn hàng có nhiều sản phẩm; một sản phẩm nằm trong nhiều đơn → nhiều-nhiều, phải tách ra bảng trung gian chi_tiet_don_hang

Bảng trung gian trong quan hệ nhiều-nhiều gần như luôn cần thêm cột riêng. chi_tiet_don_hang phải có so_luong và don_gia. Cột đơn giá phải lưu ở đây chứ không lấy từ bảng sản phẩm — vì giá sản phẩm thay đổi theo thời gian mà đơn cũ thì không được đổi theo. Đây là câu hội đồng rất hay hỏi.

Mỗi bảng cần khoá chính. Đặt tên bảng và cột thống nhất một kiểu: hoặc tất cả tiếng Việt không dấu, hoặc tất cả tiếng Anh. Trộn lẫn là bị nhắc.

Sau sơ đồ, làm bảng mô tả chi tiết từng bảng: tên cột, kiểu dữ liệu, độ dài, cho phép rỗng không, khoá, ý nghĩa. Phần này chiếm nhiều trang nhưng viết rất nhanh.

Bước 4: Sơ đồ lớp

Nếu đồ án theo hướng đối tượng thì cần thêm sơ đồ lớp. Cách nhanh: lấy ERD làm nền, mỗi bảng thành một lớp, thêm phương thức vào.

Khác biệt cần nhớ: ERD mô tả dữ liệu lưu trữ, sơ đồ lớp mô tả cả dữ liệu lẫn hành vi. Lớp có thể có phương thức không ứng với cột nào, ví dụ tinhTongTien().

Bước 5: Sơ đồ tuần tự

Chỉ vẽ cho hai đến ba luồng quan trọng nhất, thường là đăng nhập và luồng nghiệp vụ chính.

Các cột dọc theo đúng tầng trong code: Người dùng → Giao diện → Controller → Service → Repository → Cơ sở dữ liệu. Mũi tên gọi đi và mũi tên nét đứt trả về.

Vẽ đúng theo code thật của bạn. Sơ đồ vẽ năm tầng mà code chỉ có controller gọi thẳng cơ sở dữ liệu là mâu thuẫn, và hội đồng mở code ra là thấy ngay.

Kiểm tra chéo trước khi nộp

Ba chỗ phải khớp nhau, sai lệch là bị hỏi:

• Số bảng trong ERD phải khớp số bảng trong cơ sở dữ liệu thật
• Use case trong sơ đồ phải có màn hình tương ứng trong phần demo
• Tầng trong sơ đồ tuần tự phải khớp cấu trúc thư mục dự án

Đọc thêm

Cấu trúc báo cáo đồ án tốt nghiệp và số trang từng chương để biết phần này nằm ở đâu trong báo cáo.

Xem danh mục đề tài nếu muốn tham khảo sơ đồ của một hệ thống tương tự đã dựng xong — nhìn một ERD hoàn chỉnh của đề gần giống thì vẽ nhanh hơn nhiều so với tự nghĩ từ đầu.