“Trước khi biết dữ liệu đi như thế nào, hãy biết hệ thống cần làm những gì.”
1. Mở đầu
Ở bài trước, chúng ta đã biết rằng Structured Analysis nhìn một hệ thống thông tin như một tập hợp các chức năng xử lý dữ liệu.
Điều đó dẫn đến câu hỏi đầu tiên của người phân tích:
Hệ thống cần thực hiện những chức năng gì?
Đây là một câu hỏi tưởng như đơn giản nhưng lại quyết định phạm vi của toàn bộ dự án.
Nếu bỏ sót một chức năng quan trọng, hệ thống sẽ không đáp ứng được nhu cầu của tổ chức. Ngược lại, nếu đưa vào những chức năng không cần thiết, dự án sẽ trở nên phức tạp, tốn kém và khó bảo trì.
Business Function Diagram (BFD) ra đời để giải quyết chính vấn đề này.
2. Chức năng là gì?
Trong đời sống hằng ngày, chúng ta thường mô tả một hệ thống bằng những việc mà nó thực hiện.
Ví dụ, nói về một hệ thống quản lý đào tạo, chúng ta có thể liệt kê:
- Quản lý sinh viên
- Quản lý giảng 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í
- Báo cáo thống kê
Mỗi mục trong danh sách trên đều là một chức năng nghiệp vụ (Business Function).
Nói cách khác:
Chức năng là một nhóm công việc mà hệ thống phải thực hiện để hỗ trợ hoạt động của tổ chức.
Chức năng trả lời câu hỏi:
Hệ thống làm gì?
Chứ không trả lời:
- làm như thế nào,
- ai thực hiện,
- dữ liệu lưu ở đâu.
Đó là nội dung của các mô hình khác.
2. Vì sao phải xác định chức năng trước?
Giả sử một trường đại học muốn xây dựng hệ thống quản lý đào tạo.
Nếu ngay lập tức thiết kế cơ sở dữ liệu hoặc lập trình, rất dễ bỏ sót những yêu cầu quan trọng.
Ngược lại, khi bắt đầu bằng việc xác định các chức năng, nhóm phát triển sẽ có một bức tranh tổng thể về hệ thống.
Ví dụ:
Hệ thống quản lý đào tạo
├── Quản lý sinh viên
├── Quản lý giảng viên
├── Quản lý học phần
├── Đăng ký học phần
├── Quản lý điểm
└── Báo cáo thống kêDanh sách này giúp trả lời câu hỏi:
Phạm vi của hệ thống gồm những gì?
Đó chính là mục tiêu đầu tiên của BFD.
3. Business Function Diagram là gì?
Business Function Diagram (BFD) là mô hình biểu diễn cấu trúc chức năng của một hệ thống dưới dạng phân cấp.
Mỗi nút trong sơ đồ là một chức năng.
Các chức năng lớn được chia thành những chức năng nhỏ hơn cho đến khi đạt mức đủ chi tiết để tiếp tục phân tích.
Điều quan trọng cần lưu ý là:
BFD không mô tả trình tự xử lý.
Nó cũng không mô tả:
- luồng dữ liệu,
- cơ sở dữ liệu,
- người sử dụng,
- giao diện.
BFD chỉ trả lời duy nhất một câu hỏi:
Hệ thống cần thực hiện những chức năng nào?
4. Nguyên tắc phân rã chức năng
Một hệ thống lớn luôn được chia thành những phần nhỏ hơn.
Ví dụ:
Hệ thống quản lý đào tạocó thể được chia thành:
Quản lý đào tạo
├── Quản lý sinh viên
├── Quản lý học phần
├── Quản lý đăng ký
├── Quản lý điểm
└── Báo cáoTiếp tục phân rã:
Quản lý sinh viên
├── Thêm sinh viên
├── Cập nhật thông tin
├── Tra cứu
└── Khóa hồ sơMỗi lần phân rã đều nhằm biến một chức năng tổng quát thành các chức năng cụ thể hơn.
Quá trình này gọi là Functional Decomposition.
5. Khi nào nên dừng phân rã?
Đây là câu hỏi mà sinh viên thường gặp.
Không có một số lượng mức phân rã cố định.
Thông thường, nên dừng khi:
- chức năng đã đủ nhỏ để hiểu rõ,
- có thể mô tả bằng một quy trình cụ thể,
- hoặc có thể tiếp tục phân tích bằng DFD.
Nếu tiếp tục chia nhỏ đến mức mỗi thao tác chỉ còn là một câu lệnh lập trình thì BFD đã đi quá xa mục tiêu của phân tích nghiệp vụ.
Ví dụ
Một BFD đơn giản cho hệ thống quản lý thư viện có thể như sau:
Quản lý thư viện
├── Quản lý độc giả
│ ├── Thêm độc giả
│ ├── Cập nhật độc giả
│ └── Khóa thẻ
│
├── Quản lý sách
│ ├── Nhập sách
│ ├── Cập nhật sách
│ └── Thanh lý sách
│
├── Mượn trả sách
│ ├── Mượn sách
│ ├── Trả sách
│ └── Gia hạn
│
└── Báo cáoChỉ nhìn vào sơ đồ này, người đọc đã có thể hình dung phạm vi của toàn bộ hệ thống.
6. Những sai lầm thường gặp
6.1. Đồng nhất chức năng với màn hình
Ví dụ:
Màn hình A
Màn hình BĐây không phải chức năng.
Chức năng phải phản ánh nghiệp vụ.
6.2. Đồng nhất chức năng với bảng dữ liệu
Ví dụ:
Bảng SinhVien
Bảng LopHocĐây là dữ liệu.
Không phải chức năng.
6.3. Phân rã quá sâu
Ví dụ:
Đăng nhập
↓
Nhập Username
↓
Nhập Password
↓
Nhấn LoginĐây không còn là phân tích nghiệp vụ.
Đây là chi tiết giao diện.
6.4. Chức năng không cùng mức trừu tượng
Ví dụ:
Quản lý sinh viên
Đăng nhập
Báo cáo“Đăng nhập” là chức năng kỹ thuật, còn hai chức năng kia là nghiệp vụ.
Chúng không nên xuất hiện cùng một mức trong BFD.
7. Vai trò của BFD trong Structured Analysis
BFD là điểm khởi đầu của toàn bộ phương pháp.
Sau khi xác định được các chức năng, người phân tích mới có cơ sở để trả lời câu hỏi tiếp theo:
Dữ liệu sẽ đi qua các chức năng này như thế nào?
Đó chính là nhiệm vụ của Data Flow Diagram (DFD).
Có thể hình dung mối quan hệ giữa các mô hình như sau:
Business Problem
│
▼
Business Function Diagram
│
▼
Data Flow Diagram
│
▼
Entity Relationship DiagramMỗi mô hình bổ sung cho mô hình trước, tạo thành một quy trình phân tích hoàn chỉnh.
8. Tóm tắt
Business Function Diagram là mô hình đầu tiên trong Structured Analysis.
Mục tiêu của BFD không phải là mô tả quy trình hay dữ liệu, mà là xác định và tổ chức các chức năng nghiệp vụ của hệ thống theo cấu trúc phân cấp.
Một BFD tốt giúp nhóm phát triển:
- hiểu đúng phạm vi hệ thống,
- tránh bỏ sót chức năng,
- tạo nền tảng cho việc xây dựng DFD ở các bước tiếp theo.
Checklist
Sau bài học này, bạn nên trả lời được:
- Chức năng nghiệp vụ là gì?
- BFD trả lời câu hỏi nào?
- Vì sao phải xác định chức năng trước khi phân tích dữ liệu?
- Thế nào là phân rã chức năng?
- Khi nào nên dừng phân rã?
- Những sai lầm thường gặp khi xây dựng BFD là gì?
Bài tiếp theo
Sau khi xác định hệ thống cần thực hiện những chức năng gì, câu hỏi tiếp theo là:
Các chức năng đó trao đổi và xử lý dữ liệu như thế nào?
Đó chính là nội dung của bài tiếp theo về Context Diagram – mô hình đầu tiên của Data Flow Diagram (DFD), nơi chúng ta bắt đầu mô tả ranh giới hệ thống và các luồng dữ liệu giữa hệ thống với môi trường bên ngoài.