Cách Vẽ Biểu Đồ Dfd (data Flow Diagram) Chi Tiết Từ A Đến Z

1. Giới thiệu chung về DFD

1.1. DFD là gì?

Data Flow Diagram (DFD) – hay còn gọi là biểu đồ luồng dữ liệu – là một trong những công cụ quan trọng nhất trong phân tích và thiết kế hệ thống phần mềm. DFD giúp mô tả cách dữ liệu di chuyển trong hệ thống, từ các nguồn nhập (external entities) qua các quá trình xử lý (processes), lưu trữ (data stores) và cuối cùng ra các điểm xuất (external entities). Nhờ vào cách biểu diễn trực quan, DFD cho phép các nhà phân tích, nhà phát triển và cả khách hàng hiểu rõ hơn về chức năng và luồng thông tin của hệ thống mà không cần đi sâu vào chi tiết kỹ thuật.

1.2. Lợi ích của việc vẽ DFD

• Giao tiếp hiệu quả: DFD là ngôn ngữ chung giúp các bên liên quan (business analyst, developer, tester, khách hàng) dễ dàng trao đổi yêu cầu.
• Phát hiện lỗi sớm: Khi mô hình luồng dữ liệu được xây dựng, các lỗ hổng, dữ liệu thừa hoặc thiếu sẽ được phát hiện ngay trong giai đoạn phân tích.
• Cải thiện thiết kế: DFD giúp xác định các quá trình cần tối ưu, các kho dữ liệu cần chuẩn hoá và các giao diện cần xây dựng.
• Hỗ trợ tài liệu hóa: DFD là một phần quan trọng của tài liệu thiết kế hệ thống, giúp bảo trì và nâng cấp trong tương lai.

2. Các thành phần cơ bản của DFD

Trước khi bắt tay vào vẽ DFD, chúng ta cần nắm vững 4 ký hiệu chính:

Thành phần	Ký hiệu	Mô tả
External Entity (Thực thể bên ngoài)	Hình chữ nhật	Các đối tượng không thuộc hệ thống nhưng tương tác với nó (khách hàng, nhà cung cấp, hệ thống khác).
Process (Quá trình)	Hình tròn hoặc hình oval	Các chức năng xử lý dữ liệu, biến đổi dữ liệu từ đầu vào thành đầu ra.
Data Store (Kho dữ liệu)	Hình chữ nhật mở một cạnh (hoặc đôi khi là hai đường song song)	Nơi lưu trữ dữ liệu tạm thời hoặc lâu dài (cơ sở dữ liệu, file).
Data Flow (Luồng dữ liệu)	Mũi tên	Dòng dữ liệu di chuyển từ một thành phần tới thành phần khác, có thể kèm nhãn mô tả nội dung dữ liệu.

2.1. Mối quan hệ và quy tắc cơ bản

Có thể bạn quan tâm: Cách Vẽ Biểu Đồ Chart Chuẩn Và Hiệu Quả: Hướng Dẫn Từ Cơ Bản Đến Nâng Cao

• Luồng dữ liệu chỉ đi từ Entity → Process, Process → Store, Store → Process, Process → Entity, Process → Process. Không được có luồng dữ liệu trực tiếp giữa Entity và Store, hoặc giữa Store và Store.
• Mỗi Process phải có ít nhất một luồng dữ liệu vào và một luồng dữ liệu ra. Điều này đảm bảo quá trình thực sự thực hiện một công việc.
• Tên luồng dữ liệu phải ngắn gọn, mô tả rõ ràng (ví dụ: “Yêu cầu đặt hàng”, “Kết quả tính tiền”).

3. Các mức (level) của DFD

DFD được chia thành nhiều mức độ chi tiết để dễ quản lý:

1. Context Diagram (Mức 0) – Mô tả toàn bộ hệ thống dưới dạng một Process duy nhất, thể hiện tất cả các Entity bên ngoài và luồng dữ liệu chính.
2. Level 1 DFD – Phân tách Process cấp 0 thành các Process con chi tiết hơn (thường từ 3‑7 Process). Mỗi Process cấp 1 sẽ có các Entity, Store và luồng dữ liệu riêng.
3. Level 2, 3… – Khi cần, các Process cấp 1 lại được chi tiết hoá hơn nữa, tạo thành các mức sâu hơn. Tuy nhiên, không nên quá chi tiết (thường không quá 3‑4 mức) để tránh phức tạp.

4. Quy trình vẽ DFD từ A tới Z

Bước 1: Thu thập và phân tích yêu cầu

1. Phỏng vấn Stakeholder: Ghi lại các yêu cầu chức năng, phi chức năng và các thực thể bên ngoài.
2. Xác định các thực thể (External Entities): Ai/điều gì sẽ gửi dữ liệu vào hệ thống? Ai/điều gì sẽ nhận dữ liệu ra?
3. Xác định các luồng dữ liệu (Data Flows): Đặc tả dữ liệu nào được truyền giữa các thực thể và hệ thống.
4. Liệt kê các chức năng chính (Processes): Các công việc nào hệ thống cần thực hiện để đáp ứng yêu cầu.
5. Xác định kho dữ liệu (Data Stores): Dữ liệu nào cần lưu trữ, ở đâu, và cách truy cập.

Bước 2: Vẽ Context Diagram (Mức 0)

1. Vẽ một Process duy nhất (thường đặt tên “Hệ thống X”).
2. Thêm các External Entities xung quanh Process.
3. Kết nối bằng Data Flow: Đánh dấu luồng dữ liệu vào và ra với tên mô tả ngắn gọn.
4. Kiểm tra tính hợp lệ: Đảm bảo mỗi Entity có ít nhất một luồng vào/ra và không có Store xuất hiện.

Ví dụ: Đối với một hệ thống bán hàng trực tuyến, Context Diagram có thể bao gồm:
– Entity: “Khách hàng”, “Nhân viên bán hàng”, “Ngân hàng”.
– Process: “Hệ thống Bán Hàng”.
– Data Flows: “Đặt hàng”, “Xác nhận thanh toán”, “Biên lai”.

Có thể bạn quan tâm: Cách Vẽ Biểu Đồ Bánh Chuẩn Xác Và Thu Hút Người Xem: Hướng Dẫn Từ Cơ Bản Đến Nâng Cao

Bước 3: Xây dựng Level 1 DFD

1. Phân tách Process cấp 0 thành các Process con. Dựa trên các chức năng chính đã xác định (ví dụ: “Xử lý đơn hàng”, “Quản lý kho”, “Thanh toán”).
2. Đặt tên Process sao cho ngắn gọn, mô tả rõ ràng (thường dùng động từ + danh từ: “Xử lý đơn hàng”, “Cập nhật tồn kho”).
3. Thêm Data Stores: Xác định các kho dữ liệu cần thiết (ví dụ: “CSDL Đơn hàng”, “CSDL Sản phẩm”).
4. Vẽ Data Flows giữa các Process, Entity và Store. Đánh dấu luồng dữ liệu với tên chi tiết (ví dụ: “Thông tin khách hàng”, “Chi tiết đơn hàng”).
5. Kiểm tra quy tắc: Không có luồng trực tiếp Entity → Store, Store → Store; mỗi Process phải có ít nhất một luồng vào và một luồng ra.

Bước 4: Chi tiết hoá Level 2 (nếu cần)

Nếu một Process trong Level 1 vẫn quá phức tạp, bạn có thể tiếp tục chi tiết hoá:
1. Chọn Process cần chi tiết (ví dụ: “Xử lý thanh toán”).
2. Phân tách thành các sub‑process (ví dụ: “Kiểm tra thẻ”, “Gửi yêu cầu tới ngân hàng”, “Lưu giao dịch”).
3. Thêm các Data Stores phụ (ví dụ: “Log giao dịch”).
4. Vẽ lại Data Flows cho chi tiết hơn, luôn tuân thủ quy tắc.

Bước 5: Rà soát và xác nhận

1. Kiểm tra tính toàn vẹn: Mỗi luồng dữ liệu phải xuất hiện ở ít nhất một Process, không có luồng “mất” hoặc “một chiều không hợp lý”.
2. Đối chiếu với yêu cầu: Đảm bảo mọi yêu cầu chức năng đã được biểu diễn trong DFD.
3. Nhận phản hồi từ stakeholder: Trình bày DFD cho người dùng cuối, nhà quản lý, và lập trình viên để chắc chắn rằng mọi người đều hiểu đúng.
4. Cập nhật: Sửa đổi DFD dựa trên phản hồi, tạo phiên bản mới, lưu trữ lịch sử thay đổi.

Bước 6: Lưu trữ và tài liệu hoá

Có thể bạn quan tâm: Cách Vẽ Biểu Đồ Năm 2007: Hướng Dẫn Chi Tiết Từ Cơ Bản Đến Nâng Cao

• Định dạng file: Sử dụng công cụ vẽ như Microsoft Visio, Lucidchart, draw.io (diagrams.net) hoặc các phần mềm UML/DFD chuyên nghiệp. Lưu ở định dạng .vsdx, .png, .pdf để chia sẻ.
• Tên file: Đặt tên rõ ràng (ví dụ: “DFD_Level0_SalesSystem.pdf”).
• Ghi chú: Đính kèm mô tả chi tiết cho mỗi Process, Data Store và Data Flow trong tài liệu phụ (Word, Confluence).

5. Các công cụ hỗ trợ vẽ DFD

Công cụ	Ưu điểm	Nhược điểm	Giá
Microsoft Visio	Đa dạng mẫu, tích hợp Office, hỗ trợ các ký hiệu chuẩn	Đòi hỏi giấy phép, không miễn phí	~ $250/license
Lucidchart	Web‑based, cộng tác thời gian thực, mẫu DFD sẵn có	Giới hạn tính năng trong gói miễn phí	Gói miễn phí/ $7.95/user/tháng
draw.io (diagrams.net)	Miễn phí, chạy offline, tích hợp Google Drive	Giao diện không chuyên sâu như Visio	Miễn phí
Visual Paradigm	Hỗ trợ UML + DFD, version control, báo cáo	Cài đặt phức tạp, phí bản quyền	Bản cộng đồng miễn phí, bản Pro $14/month
Enterprise Architect (Sparx Systems)	Công cụ mạnh cho toàn bộ kiến trúc, DFD chuẩn	Học curve steep, chi phí cao	$239 (single user)

6. Những lỗi thường gặp khi vẽ DFD và cách khắc phục

Lỗi	Nguyên nhân	Cách khắc phục
Luồng dữ liệu “mất”	Quên kết nối luồng tới Process hoặc Store	Kiểm tra bảng danh sách luồng, dùng màu khác để đánh dấu luồng chưa hoàn thiện.
Process không có luồng vào/ra	Đặt Process nhưng chưa xác định đầu vào/đầu ra	Đảm bảo mỗi Process có ít nhất một Data Flow vào và ra.
Ký hiệu không chuẩn	Sử dụng hình dạng tùy ý, gây nhầm lẫn	Tuân thủ ký hiệu chuẩn Gane‑Sarson hoặc Yourdon.
Quá nhiều chi tiết trong một mức	Đặt quá 10 Process trong một DFD	Chia thành Level 2 hoặc tạo các Sub‑systems.
Tên luồng dữ liệu không mô tả	Sử dụng “Data1”, “Info”	Đặt tên ngắn gọn nhưng mô tả nội dung (ví dụ: “Thông tin khách hàng”).
Kết nối Entity → Store	Vi phạm quy tắc luồng dữ liệu	Thêm Process trung gian để xử lý dữ liệu trước khi lưu.

7. Thực hành: Vẽ DFD cho một hệ thống quản lý thư viện

7.1. Thu thập yêu cầu (tóm tắt)

• Người dùng: Độc giả, Thủ thư, Nhà cung cấp sách.
• Chức năng: Đăng ký thẻ thư viện, tìm kiếm sách, mượn trả sách, quản lý danh mục, báo cáo thống kê.
• Dữ liệu: Thông tin thành viên, danh mục sách, hồ sơ mượn trả, báo cáo.

7.2. Context Diagram (Mức 0)

Có thể bạn quan tâm: Cách Vẽ Biểu Đồ Bar Chuẩn Cho Người Mới Bắt Đầu: Hướng Dẫn Từ A Đến Z

• External Entities: “Độc giả”, “Thủ thư”, “Nhà cung cấp”.
• Process: “Hệ thống Quản lý Thư viện”.
• Data Flows:
• Độc giả → “Yêu cầu đăng ký” → Hệ thống
• Hệ thống → “Xác nhận thành viên” → Độc giả
• Thủ thư → “Yêu cầu cập nhật danh mục” → Hệ thống
• Hệ thống → “Báo cáo thống kê” → Thủ thư
• Nhà cung cấp → “Đề xuất sách mới” → Hệ thống

7.3. Level 1 DFD

Process	Mô tả	Data Stores
1. Đăng ký thành viên	Xử lý yêu cầu đăng ký, tạo thẻ	DS1: “CSDL Thành viên”
2. Tìm kiếm sách	Nhận từ khóa, trả về danh sách	DS2: “CSDL Sách”
3. Mượn sách	Kiểm tra điều kiện, ghi nhận mượn	DS1, DS2, DS3: “CSDL Hóa đơn mượn”
4. Trả sách	Xác nhận trả, cập nhật trạng thái	DS3
5. Quản lý danh mục	Thêm/sửa/xóa sách	DS2
6. Báo cáo	Tổng hợp thống kê mượn trả	DS1, DS2, DS3

Data Flows mẫu:
– “Thông tin đăng ký” (Độc giả → 1)
– “Xác nhận thành viên” (1 → Độc giả)
– “Yêu cầu tìm kiếm” (Độc giả → 2)
– “Kết quả tìm kiếm” (2 → Độc giả)
– “Yêu cầu mượn” (Độc giả → 3)
– “Xác nhận mượn” (3 → Độc giả)
– “Yêu cầu trả” (Độc giả → 4)
– “Xác nhận trả” (4 → Độc giả)
– “Yêu cầu cập nhật sách” (Thủ thư → 5)
– “Báo cáo thống kê” (6 → Thủ thư)

7.4. Level 2 (chi tiết Process 3 – Mượn sách)

1. Kiểm tra điều kiện mượn (sub‑process 3.1) – Kiểm tra hạn mức, trạng thái thẻ.
2. Lựa chọn sách (sub‑process 3.2) – Kiểm tra tồn kho, đặt giữ.
3. Ghi nhận giao dịch (sub‑process 3.3) – Tạo bản ghi trong DS3, cập nhật trạng thái sách trong DS2.

Data Flows:
– “Thông tin thẻ” (DS1 → 3.1)
– “Kết quả kiểm tra” (3.1 → Độc giả)
– “Yêu cầu đặt sách” (Độc giả → 3.2)
– “Xác nhận đặt” (3.2 → Độc giả)
– “Ghi nhận giao dịch” (3.3 → DS3)
– “Cập nhật tồn kho” (3.3 → DS2)

7.5. Kiểm tra và hoàn thiện

• Đảm bảo mọi Process (1‑6) đều có luồng vào và ra.
• Đảm bảo không có luồng trực tiếp Entity → Store.
• Đặt tên luồng sao cho người không chuyên cũng hiểu (ví dụ: “Danh sách sách tìm kiếm”).
• Nhận phản hồi từ thủ thư và độc giả, chỉnh sửa nếu cần.

8. Những lưu ý khi trình bày DFD trong tài liệu dự án

1. Sử dụng màu sắc hợp lý: Màu xanh cho Entity, màu cam cho Process, màu tím cho Store, màu đen cho Data Flow. Tránh dùng quá nhiều màu gây rối mắt.
2. Đánh số Process: Đánh số theo dạng “1”, “1.1”, “1.2” để dễ tham chiếu trong tài liệu mô tả chi tiết.
3. Thêm chú giải (legend): Đặt ở góc dưới cùng, giải thích ký hiệu và màu sắc.
4. Phiên bản: Ghi rõ “Phiên bản 1.0 – Ngày 12/06/2026” để quản lý thay đổi.
5. Kích thước: Đảm bảo diagram đủ lớn để đọc được chữ trên giấy A4 hoặc A3; nếu quá lớn, chia thành nhiều trang.

9. Kết luận

Việc vẽ biểu đồ DFD không chỉ là một bước trong quy trình phân tích hệ thống mà còn là công cụ giao tiếp mạnh mẽ, giúp mọi bên liên quan cùng nhau hiểu và đồng thuận về cách dữ liệu di chuyển và được xử lý trong hệ thống. Bằng cách tuân thủ quy tắc ký hiệu chuẩn, thực hiện các bước thu thập yêu cầu, vẽ Context Diagram, sau đó chi tiết hoá thành các mức DFD (Level 1, Level 2…), và luôn rà soát, nhận phản hồi, bạn sẽ có được một mô hình DFD chính xác, dễ bảo trì và hỗ trợ quá trình phát triển phần mềm hiệu quả.

Hy vọng bài viết “Cách Vẽ Biểu Đồ DFD” trên đã cung cấp cho bạn một hướng dẫn chi tiết, đầy đủ từ khái niệm cơ bản tới thực hành chi tiết cho một dự án thực tế. Hãy áp dụng những kiến thức này vào công việc của mình, và đừng quên luôn cập nhật, cải tiến DFD khi yêu cầu hệ thống thay đổi. Chúc bạn thành công trong việc thiết kế và triển khai các hệ thống phần mềm chất lượng!