Visual Paradigm Desktop | 
Visual Paradigm Online
Việc tạo sơ đồ luồng dữ liệu (DFD) là một mốc quan trọng trong phân tích hệ thống. Nó mô tả sự di chuyển của dữ liệu qua hệ thống, xác định cách thông tin được xử lý, lưu trữ và chuyển giao. Tuy nhiên, một sơ đồ trông hấp dẫn về mặt thị giác không nhất thiết chính xác về mặt chức năng. Xác minh là giai đoạn then chốt khi bạn kiểm tra xem sơ đồ có đại diện đúng yêu cầu hệ thống mà không có lỗi logic hay không. Quá trình này đảm bảo các luồng dữ liệu nhất quán, các quá trình được cân bằng và cấu trúc hỗ trợ logic kinh doanh mong muốn.
Việc xác minh không phải là một hành động đơn lẻ mà là một quá trình xem xét có kỷ luật. Nó đòi hỏi cách tiếp cận có hệ thống để kiểm tra từng yếu tố theo các quy tắc đã thiết lập. Bằng cách tuân theo quy trình xem xét có cấu trúc, bạn loại bỏ sự mơ hồ và đảm bảo sơ đồ trở thành bản vẽ thiết kế đáng tin cậy cho phát triển và giao tiếp với các bên liên quan. Hướng dẫn này nêu rõ các bước toàn diện cần thiết để xác minh DFD của bạn một cách hiệu quả, đảm bảo độ chính xác và tính nhất quán trong toàn bộ thiết kế hệ thống.
Trước khi đi vào các bước cụ thể, điều quan trọng là phải hiểu xác minh đạt được điều gì trong bối cảnh thiết kế hệ thống. Kiểm tra hỏi: ‘Chúng ta có đang xây dựng sản phẩm đúng cách không?’ Xác minh hỏi: ‘Chúng ta có đang xây dựng đúng sản phẩm không?’ Trong bối cảnh DFD, xác minh giúp lấp đầy khoảng cách giữa các yêu cầu trừu tượng và hành vi hệ thống cụ thể.
Một DFD đã được xác minh đảm bảo:
Bỏ qua giai đoạn này thường dẫn đến việc phải sửa chữa tốn kém trong giai đoạn phát triển. Những vấn đề như thiếu luồng dữ liệu hoặc kho lưu trữ dữ liệu chưa được định nghĩa sẽ rất tốn kém để khắc phục khi mã nguồn đã bắt đầu được viết. Một quy trình xem xét nghiêm ngặt sẽ giảm thiểu các rủi ro này từ sớm.
Trước khi bắt đầu xem xét chính thức, hãy đảm bảo sơ đồ đã được chuẩn bị để kiểm tra. Một sơ đồ lộn xộn hoặc được tổ chức kém sẽ khiến việc xác minh trở nên khó khăn. Sử dụng danh sách kiểm tra sau để chuẩn bị công việc của bạn:
Sơ đồ bối cảnh là mức độ trừu tượng cao nhất. Nó thể hiện hệ thống như một quá trình duy nhất và tương tác của nó với các thực thể bên ngoài. Đây là tuyến phòng thủ đầu tiên trong quá trình xác minh.
Các thực thể bên ngoài đại diện cho các nguồn hoặc điểm đến của dữ liệu nằm ngoài ranh giới hệ thống. Đảm bảo rằng mọi thực thể được hiển thị là cần thiết và được định nghĩa rõ ràng. Hãy đặt các câu hỏi sau:
Quy trình duy nhất đại diện cho hệ thống phải chứa toàn bộ logic nội bộ. Xác minh rằng không có luồng dữ liệu nào vượt qua ranh giới mà không đi qua quy trình này. Nếu dữ liệu di chuyển từ một thực thể bên ngoài này sang thực thể bên ngoài khác mà không đi vào hệ thống, thì nó không nên được hiển thị trên sơ đồ ngữ cảnh, vì nó nằm ngoài phạm vi.
Xem xét từng mũi tên kết nối với quy trình trung tâm. Mỗi đầu vào phải có hành động đầu ra tương ứng hoặc lưu trữ. Nếu một luồng dữ liệu đi vào hệ thống nhưng không có dữ liệu nào thoát ra, điều đó có thể cho thấy một quy trình “lỗ đen”, nơi dữ liệu biến mất mà không lý do rõ ràng.
Sơ đồ DFD cấp độ 0 phân tích quy trình duy nhất trong sơ đồ ngữ cảnh thành các hệ thống con chính. Quy tắc quan trọng nhất ở đây làcân bằng. Các đầu vào và đầu ra của quy trình cha phải khớp chính xác với các đầu vào và đầu ra của các quy trình con.
Với mỗi luồng dữ liệu đi vào quy trình sơ đồ ngữ cảnh, phải có một luồng dữ liệu tương ứng đi vào sơ đồ cấp độ 0. Điều này cũng áp dụng cho đầu ra. Điều này được gọi là bảo toàn dữ liệu. Nếu sơ đồ ngữ cảnh hiển thị “Đơn hàng khách hàng” đi vào hệ thống, sơ đồ cấp độ 0 phải hiển thị “Đơn hàng khách hàng” đi vào ít nhất một trong các quy trình chính.
Cấp độ 0 thường chứa từ 3 đến 7 quy trình. Nếu bạn có nhiều hơn 7 quy trình, sơ đồ có thể quá phức tạp cho một cái nhìn duy nhất. Nếu bạn có ít hơn 3 quy trình, bạn có thể cần phân tích sâu hơn. Đảm bảo mỗi quy trình là riêng biệt và thực hiện một chức năng logic duy nhất.
Kiểm tra xem mỗi kho dữ liệu ở cấp độ 0 có thực sự cần thiết hay không. Một kho dữ liệu chỉ nên tồn tại nếu dữ liệu cần được lưu giữ để sử dụng sau này. Đảm bảo các luồng dữ liệu đi vào và ra khỏi kho được ghi nhãn chính xác. Các kho dữ liệu không nên kết nối trực tiếp với các thực thể bên ngoài; mọi dữ liệu phải đi qua một quy trình.
Sơ đồ cấp độ N cung cấp thêm chi tiết cho các quy trình cụ thể được xác định ở cấp độ 0. Việc xác minh ở cấp độ này tập trung vào tính nhất quán với quy trình cha.
Giống như cấp độ 0, các đầu vào và đầu ra của quy trình cha phải khớp với tổng các đầu vào và đầu ra của các quy trình con. Nếu quy trình 1.0 nhận “Dữ liệu đăng nhập” và xuất “Token truy cập” trong sơ đồ cấp độ 0, thì việc phân tích quy trình 1.0 ở cấp độ 1 cũng phải chấp nhận “Dữ liệu đăng nhập” và tạo ra “Token truy cập”.
Đảm bảo rằng việc phân tích là hợp lý. Sơ đồ con có giải thíchcáchquy trình cha hoạt động như thế nào không? Tránh đưa vào các thực thể bên ngoài hoặc kho dữ liệu mới trong sơ đồ con mà không được ngụ ý từ quy trình cha. Nếu một kho dữ liệu mới được giới thiệu, nó phải được biện minh bằng yêu cầu lưu giữ dữ liệu.
Các nhãn trên các luồng dữ liệu trong sơ đồ con phải khớp với các nhãn trong sơ đồ cha khi có thể. Nếu một luồng được tinh chỉnh trong sơ đồ con (ví dụ: “Dữ liệu” trở thành “Dữ liệu người dùng”), sự thay đổi đó phải nhất quán với từ điển dữ liệu. Sự mơ hồ ở đây sẽ gây nhầm lẫn trong quá trình triển khai.
Có những bất thường cấu trúc cụ thể cho thấy lỗi trong thiết kế DFD. Những mẫu phổ biến này phải được xác định và sửa chữa trong quá trình xác minh.
Một quy trình lỗ đen là quy trình có đầu vào nhưng không có đầu ra. Dữ liệu đi vào quy trình và biến mất. Điều này thường cho thấy thiếu luồng đầu ra hoặc định nghĩa quy trình chưa hoàn chỉnh. Mọi quy trình đều phải tạo ra kết quả nào đó, có thể là dữ liệu để lưu trữ, dữ liệu để gửi đi nơi khác, hoặc kết quả quyết định.
Một quy trình phép màu là quy trình có đầu ra nhưng không có đầu vào. Nó tạo ra dữ liệu từ không có gì. Điều này là không thể về mặt logic trong thiết kế hệ thống. Mọi đầu ra đều phải được tạo ra từ dữ liệu đầu vào hoặc suy ra từ dữ liệu đã lưu trữ.
Một lỗ xám xảy ra khi đầu vào không phù hợp với đầu ra về mặt logic. Ví dụ, nếu đầu vào là ‘Địa chỉ khách hàng’ và đầu ra là ‘Chi tiết thanh toán’, thì quy trình đang thực hiện nhiều hơn chỉ việc chuyển đổi; nó đang tạo ra dữ liệu không thể suy ra từ đầu vào. Điều này cho thấy có luồng dữ liệu bị thiếu hoặc có kho dữ liệu bị thiếu.
Đảm bảo rằng luồng dữ liệu không đi trực tiếp từ một thực thể bên ngoài đến kho dữ liệu. Mọi dữ liệu vào hoặc ra khỏi kho đều phải đi qua một quy trình. Điều này đảm bảo rằng các quy tắc toàn vẹn dữ liệu và logic kinh doanh được áp dụng trước khi dữ liệu được lưu trữ.
Sử dụng bảng này như một tham chiếu nhanh trong các buổi xem xét của bạn. Bảng này tóm tắt các quy tắc chính và các kiểm tra cụ thể cần thiết cho từng phần tử.
| Phần tử | Quy tắc xác minh | Lỗi phổ biến |
|---|---|---|
| Quy trình | Phải có ít nhất một đầu vào và một đầu ra | Quy trình lỗ đen hoặc quy trình phép màu |
| Kho dữ liệu | Phải được kết nối với một quy trình, không phải với một thực thể | Luồng trực tiếp từ thực thể đến kho |
| Luồng dữ liệu | Phải được đánh nhãn bằng cụm danh từ | Nhãn động từ hoặc nhãn bị thiếu |
| Thực thể bên ngoài | Phải nằm ngoài biên giới hệ thống | Thực thể nằm trong biên giới hệ thống |
| Tính nhất quán | Đầu vào/đầu ra của cha và con phải khớp nhau | Luồng dữ liệu mất cân bằng |
| Phân rã | Con phải giải thích ‘Làm thế nào’, chứ không phải ‘Tại sao’ | Thêm logic nằm ngoài phạm vi |
Kiểm tra tính hợp lệ không chỉ là một kiểm tra kỹ thuật; nó là một công cụ giao tiếp. Khi các quy tắc kỹ thuật đã được đáp ứng, sơ đồ phải được xem xét bởi các bên liên quan để đảm bảo nó đáp ứng nhu cầu kinh doanh.
Không trình bày sơ đồ một cách tách biệt. Chuẩn bị một bản trình bày chi tiết giải thích luồng dữ liệu. Cung cấp bối cảnh về lý do tại sao một số kho dữ liệu tồn tại và cách các quy trình tương tác với nhau. Đảm bảo tất cả các bên liên quan đều có quyền truy cập vào từ điển dữ liệu để hiểu được thuật ngữ.
Khuyến khích các bên liên quan đặt câu hỏi về luồng dữ liệu. Đặt những câu hỏi cụ thể như:
Ghi lại tất cả phản hồi và các thay đổi đề xuất. Nếu một bên liên quan đề xuất một luồng dữ liệu mới, hãy xác minh nó theo các quy tắc cân bằng trước khi chấp nhận. Cập nhật sơ đồ và từ điển dữ liệu đồng thời để duy trì sự đồng bộ. Việc quản lý phiên bản là rất quan trọng; hãy lưu trữ hồ sơ trạng thái sơ đồ tại mỗi vòng xem xét.
Việc kiểm tra tính hợp lệ hiếm khi là một sự kiện duy nhất. Khi yêu cầu thay đổi, sơ đồ luồng dữ liệu (DFD) phải thay đổi theo. Phần này trình bày cách quản lý các thay đổi trong suốt vòng đời của dự án.
Khi có yêu cầu thay đổi, hãy phân tích tác động của nó đối với toàn bộ cấu trúc phân cấp. Nếu một quy trình ở cấp độ 1 thay đổi, nó có ảnh hưởng đến cấp độ 0 không? Liệu có cần kho dữ liệu mới không? Nó có ảnh hưởng đến các quy trình khác chia sẻ cùng luồng dữ liệu không? Việc thực hiện phân tích tác động này giúp ngăn ngừa các lỗi lan truyền.
Duy trì lịch sử rõ ràng về các phiên bản sơ đồ. Sử dụng số phiên bản (ví dụ: v1.0, v1.1) và ngày sửa đổi. Điều này giúp đội ngũ theo dõi quá trình phát triển thiết kế hệ thống và có thể hoàn nguyên thay đổi nếu cần. Mặc dù không yêu cầu công cụ cụ thể, nhưng việc tuân thủ quy tắc đặt tên rõ ràng cho các tệp là thiết yếu.
Sau khi thực hiện các thay đổi, hãy chạy lại quy trình kiểm tra tính hợp lệ. Đừng cho rằng một thay đổi nhỏ sẽ bảo toàn tính toàn vẹn của toàn bộ hệ thống. Kiểm tra lại các quy tắc cân bằng, quy tắc đặt tên và tính toàn vẹn cấu trúc. Đôi khi một thay đổi nhỏ có thể làm mất cân bằng sơ đồ đã được kiểm tra trước đó.
Từ điển dữ liệu là nền tảng của sơ đồ luồng dữ liệu của bạn. Nó định nghĩa cấu trúc của từng phần tử dữ liệu. Việc kiểm tra tính hợp lệ phải được mở rộng từ sơ đồ trực quan sang các định nghĩa văn bản.
Đảm bảo các nhãn luồng dữ liệu trên sơ đồ khớp chính xác với các mục trong từ điển. Nếu sơ đồ ghi “Mã hóa đơn” còn từ điển ghi “Mã định danh hóa đơn”, sự không nhất quán này có thể gây nhầm lẫn trong quá trình thiết kế cơ sở dữ liệu. Chuẩn hóa thuật ngữ trên tất cả tài liệu.
Kiểm tra xem mỗi kho dữ liệu có cấu trúc được định nghĩa rõ ràng trong từ điển hay không. Liệt kê các thuộc tính, kiểu dữ liệu và ràng buộc khóa. Nếu một kho dữ liệu được tham chiếu trong DFD nhưng không có mục trong từ điển, thiết kế sẽ chưa hoàn chỉnh. Khoảng trống này thường dẫn đến lỗi cơ sở dữ liệu sau này.
Xác minh rằng kiểu dữ liệu ngầm định trong sơ đồ phù hợp với các quy tắc kinh doanh. Ví dụ, nếu một luồng dữ liệu đại diện cho “Ngày sinh”, thì nó không được xử lý như một chuỗi văn bản trong từ điển. Nó phải có định dạng ngày tháng. Mức độ chi tiết này đảm bảo rằng triển khai kỹ thuật phù hợp với thiết kế khái niệm.
Ngay cả những nhà phân tích có kinh nghiệm cũng gặp phải những bẫy cụ thể trong quá trình kiểm tra tính hợp lệ. Việc nhận thức được những sai lầm phổ biến này sẽ giúp bạn xử lý quá trình xem xét hiệu quả hơn.
Sau khi kiểm tra xác nhận hoàn tất, tài liệu phải được hoàn thiện để bàn giao cho đội phát triển. Việc này bao gồm việc tổng hợp các sơ đồ, từ điển dữ liệu và báo cáo kiểm tra xác nhận.
Thu thập tất cả sơ đồ cấp 0, sơ đồ cấp N và sơ đồ bối cảnh vào một gói duy nhất. Đảm bảo phân cấp được đánh dấu rõ ràng để các nhà phát triển có thể theo dõi quá trình phân tích. Bao gồm từ điển dữ liệu như tài liệu đi kèm.
Tạo báo cáo tóm tắt quá trình kiểm tra xác nhận. Liệt kê các vấn đề phát hiện trong quá trình xem xét và cách thức khắc phục. Tài liệu này đóng vai trò là bằng chứng cho thấy thiết kế đã được kiểm tra kỹ lưỡng. Đồng thời, nó cung cấp bối cảnh cho những người bảo trì trong tương lai, những người có thể không tham gia vào cuộc xem xét ban đầu.
Xác định quy trình bàn giao các sơ đồ luồng dữ liệu đã được xác nhận. Quy trình này nên bao gồm một buổi họp nơi thiết kế được giải thích cho đội phát triển. Giải đáp mọi thắc mắc liên quan đến các luồng mơ hồ hoặc các kho dữ liệu phức tạp. Đảm bảo đội ngũ hiểu rằng sơ đồ luồng dữ liệu là nguồn thông tin chính xác cho các yêu cầu dữ liệu.
Công việc không kết thúc ở giai đoạn xác nhận. Sơ đồ phải luôn được giữ đúng khi hệ thống phát triển. Xây dựng quy trình quản trị cho các thay đổi trong tương lai.
Bằng cách tuân thủ các bước xác nhận này, bạn đảm bảo rằng sơ đồ luồng dữ liệu của mình được bền vững, chính xác và hữu ích trong suốt vòng đời hệ thống. Kỷ luật này giảm thiểu sự mơ hồ, ngăn ngừa các lỗi tốn kém và tạo nền tảng vững chắc cho việc phát triển hệ thống thành công.