“Muốn hiểu một hệ thống, trước hết phải biết hệ thống bắt đầu ở đâu và kết thúc ở đâu.”
1. Mở đầu
Ở bài trước, chúng ta đã xác định hệ thống cần thực hiện những chức năng gì bằng Business Function Diagram (BFD).
Nhờ đó, người phân tích có một bức tranh tổng thể về phạm vi chức năng của hệ thống.
Tuy nhiên, một câu hỏi khác ngay lập tức xuất hiện:
Hệ thống sẽ trao đổi dữ liệu với ai?
Không có hệ thống thông tin nào hoạt động một cách độc lập.
Một hệ thống quản lý đào tạo phải nhận dữ liệu từ sinh viên, giảng viên và phòng đào tạo.
Một hệ thống bán hàng phải trao đổi dữ liệu với khách hàng, nhà cung cấp và đơn vị vận chuyển.
Một hệ thống ngân hàng phải kết nối với khách hàng, ATM, Internet Banking và nhiều hệ thống khác.
Trước khi đi sâu vào các quy trình xử lý bên trong, người phân tích cần xác định ranh giới của hệ thống và những luồng dữ liệu đi qua ranh giới đó.
Đó chính là mục tiêu của Context Diagram.
2. Vì sao cần xác định ranh giới hệ thống?
Trong thực tế, rất nhiều dự án thất bại không phải vì kỹ thuật, mà vì phạm vi hệ thống không được xác định rõ.
Ví dụ, một trường đại học triển khai hệ thống quản lý đào tạo.
Nếu không xác định ranh giới ngay từ đầu, sẽ rất dễ phát sinh các câu hỏi như:
- Hệ thống có quản lý ký túc xá không?
- Có quản lý thư viện không?
- Có tích hợp thanh toán trực tuyến không?
- Có gửi email tự động không?
Những câu hỏi này không liên quan đến kỹ thuật.
Chúng liên quan đến phạm vi của hệ thống.
Context Diagram giúp trả lời:
Hệ thống chịu trách nhiệm những gì và không chịu trách nhiệm những gì.
3. Context Diagram là gì?
Context Diagram là mức cao nhất của Data Flow Diagram (DFD).
Nó mô tả hệ thống như một tiến trình duy nhất (single process) và thể hiện cách hệ thống trao đổi dữ liệu với các thực thể bên ngoài.
Điều quan trọng cần lưu ý là:
Context Diagram không mô tả cách hệ thống xử lý dữ liệu.
Nó chỉ trả lời hai câu hỏi:
- Hệ thống giao tiếp với ai?
- Dữ liệu nào được trao đổi?
4. Ba thành phần của Context Diagram
Một Context Diagram chỉ gồm ba thành phần.
4.1. Hệ thống (System)
Toàn bộ hệ thống được biểu diễn bằng một tiến trình duy nhất.
Ví dụ:
Hệ thống Quản lý Đào tạoBên trong không mô tả bất kỳ chức năng nào.
Mọi xử lý chi tiết sẽ được thể hiện ở các mức DFD sau.
4.2. Thực thể bên ngoài (External Entity)
External Entity là những đối tượng nằm ngoài phạm vi hệ thống nhưng có trao đổi dữ liệu với hệ thống.
Ví dụ:
- Sinh viên
- Giảng viên
- Phòng Đào tạo
- Hệ thống Thanh toán
Các thực thể này không thuộc hệ thống, nhưng hệ thống cần tương tác với chúng.
4.3. Luồng dữ liệu (Data Flow)
Data Flow biểu diễn dữ liệu được gửi hoặc nhận giữa hệ thống và các thực thể bên ngoài.
Ví dụ:
Sinh viên gửi:
- Phiếu đăng ký học phần
Hệ thống trả về:
- Kết quả đăng ký
Điều cần mô tả là dữ liệu, không phải hành động.
Ví dụ:
✔ Đúng
- Thông tin sinh viên
- Phiếu đăng ký
- Danh sách lớp
✘ Sai
- Đăng ký học phần
- Xem điểm
- Tra cứu
Những cụm từ này mô tả hành động chứ không phải dữ liệu.
Ví dụ
Đối với hệ thống quản lý đào tạo, Context Diagram có thể được mô tả như sau:
+----------------+
| Sinh viên |
+----------------+
| ^
Phiếu đăng ký | | Kết quả đăng ký
v |
+---------------------------+
| Hệ thống Quản lý Đào tạo |
+---------------------------+
^ |
Danh sách lớp | | Bảng điểm
| v
+----------------+
| Phòng Đào tạo |
+----------------+Chỉ với một sơ đồ đơn giản, người đọc đã có thể hiểu:
- hệ thống phục vụ ai,
- nhận dữ liệu gì,
- cung cấp dữ liệu gì.
5. Context Diagram không thể hiện điều gì?
Đây là điểm sinh viên rất dễ nhầm.
Context Diagram không thể hiện:
- các chức năng bên trong,
- cơ sở dữ liệu,
- thuật toán xử lý,
- thứ tự các bước,
- giao diện người dùng.
Nếu sơ đồ bắt đầu xuất hiện:
- Đăng ký học phần
- Kiểm tra điều kiện
- Lưu dữ liệu
thì bạn đã chuyển sang DFD Level 0, không còn là Context Diagram nữa.
6. Những sai lầm thường gặp
6.1. Vẽ nhiều Process
Context Diagram chỉ có một Process.
Nếu có nhiều Process, đó không còn là Context Diagram.
6.2. Đưa Data Store vào Context Diagram
Đây là lỗi rất phổ biến.
Context Diagram không mô tả dữ liệu lưu trữ.
Data Store chỉ xuất hiện từ DFD Level 0.
6.3. Dùng tên hành động thay cho dữ liệu
Ví dụ:
✘ Đăng nhập
✘ Thanh toán
✘ Đăng ký học
Đây là các hành động.
Data Flow phải là:
✔ Thông tin đăng nhập
✔ Thông tin thanh toán
✔ Phiếu đăng ký học phần
6.4. Đưa Actor nội bộ thành External Entity
Ví dụ:
Nhân viên phòng đào tạo sử dụng hệ thống.
Nếu họ là người dùng của hệ thống thì đúng là External Entity.
Nhưng nếu bạn vẽ:
“Cơ sở dữ liệu”
“Máy chủ”
thành External Entity thì không đúng.
7. Context Diagram trong quy trình Structured Analysis
Đến đây, chúng ta đã hoàn thành hai bước đầu tiên.
Business Problem
│
▼
Business Function Diagram
│
▼
Context DiagramBFD giúp xác định:
Hệ thống cần làm gì?
Context Diagram giúp xác định:
Hệ thống giao tiếp với ai?
Hai mô hình bổ sung cho nhau.
Một mô hình mô tả phạm vi chức năng.
Một mô hình mô tả phạm vi trao đổi dữ liệu.
8. Tóm tắt
Context Diagram là mức cao nhất của Data Flow Diagram.
Mục tiêu của nó là xác định ranh giới của hệ thống và mô tả các luồng dữ liệu giữa hệ thống với môi trường bên ngoài.
Một Context Diagram chỉ gồm ba thành phần:
- Hệ thống.
- Thực thể bên ngoài.
- Luồng dữ liệu.
Không mô tả xử lý bên trong, không mô tả cơ sở dữ liệu và cũng không mô tả quy trình nghiệp vụ.
Đó là nhiệm vụ của các mức DFD tiếp theo.
Checklist
Sau bài học này, bạn nên trả lời được:
- Context Diagram là gì?
- Vì sao phải xác định ranh giới hệ thống?
- Ba thành phần của Context Diagram là gì?
- Data Flow khác hành động ở điểm nào?
- Những gì không được xuất hiện trong Context Diagram?
- Context Diagram khác BFD ở điểm nào?
9. Góc nhìn nghề nghiệp
Trong các dự án hiện đại, Context Diagram không chỉ xuất hiện trong Structured Analysis mà còn được sử dụng rộng rãi trong giai đoạn xác định phạm vi hệ thống (System Scope) hoặc mô hình hóa bối cảnh (System Context). Nhiều Business Analyst và Solution Architect vẫn sử dụng một sơ đồ tương tự để thống nhất với khách hàng về ranh giới của hệ thống, các hệ thống bên ngoài cần tích hợp và các luồng thông tin chính trước khi đi vào thiết kế chi tiết.
Bài tiếp theo
Context Diagram cho chúng ta cái nhìn từ bên ngoài vào hệ thống.
Ở bài tiếp theo, chúng ta sẽ “mở” hệ thống đó ra bằng Data Flow Diagram Level 0, nơi tiến trình duy nhất của Context Diagram được phân rã thành các tiến trình chính. Khi đó, chúng ta sẽ trả lời câu hỏi:
Dữ liệu được xử lý như thế nào bên trong hệ thống?
Đây chính là bước bắt đầu đi vào “trái tim” của phương pháp Structured Analysis.