“Một sơ đồ tốt không phải là sơ đồ có nhiều chi tiết, mà là sơ đồ được phân rã đúng mức.”
1. Mở đầu
Ở bài trước, chúng ta đã xây dựng DFD Level 0 để mô tả các tiến trình chính của hệ thống.
Ví dụ, đối với hệ thống quản lý đào tạo, DFD Level 0 có thể gồm các tiến trình:
- Quản lý sinh viên
- Quản lý học phần
- Đăng ký học phần
- Quản lý điểm
- Quản lý học phí
Nhưng nếu nhìn vào tiến trình Đăng ký học phần, chúng ta sẽ thấy một vấn đề.
Tên tiến trình đã cho biết hệ thống làm gì, nhưng chưa cho biết hệ thống thực hiện việc đó như thế nào.
Ví dụ, khi sinh viên đăng ký học phần, hệ thống cần:
- tiếp nhận yêu cầu đăng ký;
- kiểm tra điều kiện tiên quyết;
- kiểm tra số lượng chỗ còn trống;
- lưu kết quả đăng ký;
- gửi phản hồi cho sinh viên.
Nếu tất cả các bước này đều nằm trong một Process duy nhất, DFD sẽ quá tổng quát và khó sử dụng.
Đó là lý do DFD Level 1 được xây dựng.
2. Vì sao cần phân rã Process?
Một Process ở DFD Level 0 thường đại diện cho một nhóm chức năng nghiệp vụ.
Trong thực tế, mỗi nhóm chức năng lại bao gồm nhiều bước xử lý nhỏ hơn.
Ví dụ:
Đăng ký học phầnkhông phải là một thao tác duy nhất.
Nó bao gồm nhiều bước liên tiếp.
Nếu không phân rã, người đọc sẽ không hiểu:
- dữ liệu được kiểm tra ở đâu;
- dữ liệu được lưu khi nào;
- dữ liệu nào được tạo mới;
- dữ liệu nào được cập nhật.
DFD Level 1 giúp mô hình hóa các bước xử lý này.
3. DFD Level 1 là gì?
DFD Level 1 là sơ đồ mô tả chi tiết một Process của DFD Level 0.
Nói cách khác:
- DFD Level 0 mô tả toàn bộ hệ thống.
- DFD Level 1 mô tả một tiến trình trong hệ thống.
Ví dụ:
DFD Level 0
3.0 Đăng ký học phầnđược phân rã thành:
3.1 Tiếp nhận đăng ký
3.2 Kiểm tra điều kiện
3.3 Kiểm tra số lượng
3.4 Lưu đăng ký
3.5 Thông báo kết quảĐây chính là nội dung của DFD Level 1.
4. Nguyên tắc phân rã
Việc phân rã không phải là chia nhỏ tùy ý.
Mỗi Process con phải góp phần hoàn thành Process cha.
Ví dụ:
3.0 Đăng ký học phầncó thể được phân rã như sau:
3.1 Tiếp nhận yêu cầu
↓
3.2 Kiểm tra điều kiện tiên quyết
↓
3.3 Kiểm tra số lượng lớp
↓
3.4 Cập nhật dữ liệu đăng ký
↓
3.5 Trả kết quảNếu bỏ đi một Process con, Process cha sẽ không còn hoàn chỉnh.
Đây là dấu hiệu cho thấy việc phân rã hợp lý.
5. Đánh số Process
Trong DFD, việc đánh số giúp thể hiện quan hệ phân cấp giữa các mức.
Ví dụ:
Level 0
1.0 Quản lý sinh viên
2.0 Quản lý học phần
3.0 Đăng ký học phần
4.0 Quản lý điểmSau đó:
Level 1 của Process 3.0
3.1 Tiếp nhận yêu cầu
3.2 Kiểm tra điều kiện
3.3 Kiểm tra số lượng
3.4 Lưu đăng ký
3.5 Trả kết quảLưu ý:
Các số không biểu diễn thứ tự thực hiện, mà chỉ biểu diễn quan hệ phân cấp.
6. Nguyên tắc Balancing
Đây là nguyên tắc quan trọng nhất của DFD.
Balancing có nghĩa là:
Process cha và Process con phải có cùng phạm vi trao đổi dữ liệu với bên ngoài.
Ví dụ.
Ở DFD Level 0:
Sinh viên
↓
Phiếu đăng ký
↓
3.0 Đăng ký học phần
↓
Kết quả đăng ký
↓
Sinh viênKhi phân rã thành DFD Level 1:
Sinh viên
↓
Phiếu đăng ký
↓
3.1 Tiếp nhận yêu cầu
...
↓
3.5 Trả kết quả
↓
Kết quả đăng ký
↓
Sinh viênLuồng dữ liệu vào và ra vẫn phải giữ nguyên.
Không được:
- thêm một luồng dữ liệu mới từ Sinh viên;
- hoặc làm mất luồng dữ liệu đã có.
Nếu thay đổi, DFD Level 1 sẽ không còn phản ánh đúng Process cha.
Ví dụ
Ví dụ đơn giản:
Level 0
Sinh viên
↓
Phiếu đăng ký
↓
3.0 Đăng ký học phần
↓
Kết quả đăng ký
↓
Sinh viênDFD Level 1:
Sinh viên
↓
Phiếu đăng ký
↓
3.1 Tiếp nhận yêu cầu
↓
3.2 Kiểm tra điều kiện
↓
3.3 Kiểm tra số lượng
↓
3.4 Cập nhật đăng ký
↓
3.5 Trả kết quả
↓
Kết quả đăng ký
↓
Sinh viênNhìn vào hai sơ đồ, người đọc thấy:
- phạm vi không thay đổi;
- chỉ có mức độ chi tiết tăng lên.
Đó chính là Balancing.
8. Khi nào nên dừng phân rã?
Đây là câu hỏi rất phổ biến.
Không có quy định cứng về số mức DFD.
Thông thường, nên dừng khi Process:
- đủ nhỏ để mô tả rõ logic xử lý;
- có thể viết Process Specification;
- hoặc có thể chuyển sang thiết kế.
Nếu tiếp tục phân rã đến mức:
Nhập mã sinh viên
↓
Nhấn nút Tìm kiếm
↓
Hiển thị kết quảthì bạn đã đi vào thiết kế giao diện, không còn là phân tích hệ thống.
9. Những sai lầm thường gặp
* Phân rã theo màn hình
Ví dụ:
Màn hình A
↓
Màn hình BĐây không phải Process.
* Phân rã quá sâu
DFD không mô tả từng thao tác của người dùng.
Mục tiêu là mô hình hóa nghiệp vụ.
* Mất Balancing
Ví dụ:
Level 0 có:
Phiếu đăng kýLevel 1 lại xuất hiện:
Thông tin thanh toánNếu dữ liệu này chưa từng xuất hiện ở Process cha thì mô hình đã mất tính nhất quán.
* Process con không liên quan Process cha
Ví dụ:
3.0 Đăng ký học phầnLevel 1 lại có:
Quản lý giảng viênĐây là chức năng khác.
Không thuộc Process cha.
10. Vai trò của DFD Level 1
Nếu Context Diagram giúp xác định ranh giới hệ thống, DFD Level 0 giúp xác định các tiến trình chính, thì DFD Level 1 là nơi người phân tích bắt đầu mô tả logic nghiệp vụ.
Đây cũng là mức DFD được sử dụng nhiều nhất trong thực tế vì đủ chi tiết để:
- trao đổi với người dùng;
- rà soát nghiệp vụ;
- làm cơ sở xây dựng Process Specification.
11. Tóm tắt
DFD Level 1 là bước phân rã một Process trong DFD Level 0 thành các Process nhỏ hơn.
Mục tiêu không phải là chia nhỏ tối đa, mà là làm rõ cách dữ liệu được xử lý.
Một DFD Level 1 tốt cần tuân thủ ba nguyên tắc:
- Phân rã đúng phạm vi của Process cha.
- Đánh số theo quan hệ phân cấp.
- Đảm bảo Balancing giữa các mức DFD.
Nhờ đó, toàn bộ mô hình luôn nhất quán và dễ mở rộng.
Checklist
Sau bài học này, bạn nên trả lời được:
- DFD Level 1 khác DFD Level 0 ở điểm nào?
- Khi nào cần phân rã một Process?
- Quy tắc đánh số Process là gì?
- Balancing là gì và vì sao quan trọng?
- Khi nào nên dừng phân rã?
Góc nhìn nghề nghiệp
Trong các dự án hiện đại, ít nhóm phát triển xây dựng DFD đến nhiều mức như trước đây. Tuy nhiên, tư duy phân rã từ tổng quát đến chi tiết và giữ tính nhất quán giữa các mức mô hình vẫn được áp dụng rộng rãi, từ phân tích quy trình nghiệp vụ, thiết kế API cho đến phân chia microservices. Vì vậy, giá trị của DFD Level 1 không chỉ nằm ở sơ đồ, mà còn ở phương pháp tư duy có hệ thống khi phân tích một bài toán phức tạp.
Bài tiếp theo
Đến đây, chúng ta đã biết dữ liệu đi qua các Process như thế nào. Tuy nhiên, trên các sơ đồ DFD, các luồng dữ liệu mới chỉ được biểu diễn bằng tên như Phiếu đăng ký, Danh sách học phần hay Bảng điểm.
Nhưng những dữ liệu đó thực sự gồm những trường thông tin nào? Quy ước đặt tên ra sao? Có cấu trúc như thế nào?
Đó là nội dung của Bài 6 – Data Dictionary, nơi chúng ta xây dựng “từ điển dữ liệu” để mọi thành viên trong dự án cùng hiểu và sử dụng dữ liệu theo một cách thống nhất.