Phân tích thiết kế hệ thống thông tin quản lý

Bài 14. Activity Diagram – Mô hình hóa quy trình nghiệp vụ

“Use Case trả lời người dùng muốn làm gì. Activity Diagram trả lời công việc đó diễn ra như thế nào.”

Theo tôi, Activity Diagram mới là sơ đồ quan trọng nhất đối với một System Analyst.

Đây là quan điểm hơi khác với nhiều giáo trình.

Rất nhiều trường dành nhiều thời gian cho Use Case Diagram. Trong khi thực tế, ở doanh nghiệp, sơ đồ được sử dụng nhiều nhất khi trao đổi với khách hàng lại là Activity Diagram, bởi nó mô tả đúng cách một quy trình nghiệp vụ vận hành.

Một khách hàng có thể không hiểu Sequence Diagram hay Class Diagram, nhưng họ gần như luôn hiểu một Activity Diagram được xây dựng tốt.

Vì vậy, Bài 14 tôi không hướng dẫn “cách vẽ UML”, mà dạy cách mô hình hóa quy trình nghiệp vụ.

Vị trí của bài học trong chuỗi bài

Business Problem
        ↓
Stakeholder
        ↓
AS-IS Process
        ↓
Gap Analysis
        ↓
TO-BE Process
        ↓
Requirement Engineering
        ↓
Use Case
        ↓
Use Case Specification
        ↓
Use Case Diagram
        ↓
Activity Diagram   ← Bạn đang ở đây
        ↓
Sequence Diagram
        ↓
Domain Model

Mục tiêu bài học

Sau khi hoàn thành bài học này, bạn có thể:

  • Hiểu mục đích của Activity Diagram.
  • Phân biệt Activity Diagram với Flowchart.
  • Mô hình hóa một quy trình nghiệp vụ bằng Activity Diagram.
  • Biết sử dụng các ký hiệu cơ bản của UML.
  • Tránh những sai lầm phổ biến khi xây dựng Activity Diagram.

1. Vì sao cần Activity Diagram?

Giả sử bạn có Use Case:

Đăng ký học phần

Tên Use Case cho biết:

Sinh viên muốn đăng ký học phần.

Nhưng nó không cho biết:

  • Bắt đầu từ đâu?
  • Thực hiện những bước nào?
  • Nếu học phần đã đầy thì sao?
  • Nếu chưa đạt điều kiện tiên quyết thì sao?
  • Khi nào quy trình kết thúc?

Đó là lúc Activity Diagram phát huy vai trò.

Nó mô tả luồng công việc (workflow) từ đầu đến cuối.

2. Activity Diagram là gì?

Activity Diagram là sơ đồ UML dùng để mô tả:

  • Trình tự các hoạt động.
  • Các quyết định trong quy trình.
  • Các nhánh xử lý.
  • Các hoạt động song song.
  • Điểm bắt đầu và kết thúc của quy trình.

Nói ngắn gọn:

Activity Diagram mô tả cách công việc được thực hiện.

3. Activity Diagram khác Flowchart như thế nào?

Đây là câu hỏi rất nhiều sinh viên đặt ra.

Thực tế, hai loại sơ đồ có nhiều điểm giống nhau, nhưng mục đích sử dụng khác nhau.

FlowchartActivity Diagram
Mô tả thuật toán hoặc quy trình đơn giảnMô tả quy trình nghiệp vụ hoặc hành vi hệ thống
Thường dùng trong lập trìnhThường dùng trong phân tích và thiết kế hệ thống
Ít thể hiện vai trò thực hiệnCó thể phân chia theo Actor hoặc bộ phận (Swimlane)
Không thuộc UMLLà một sơ đồ UML

Nếu đang phân tích một quy trình nghiệp vụ, Activity Diagram thường là lựa chọn phù hợp hơn.

4. Các ký hiệu cơ bản

Bạn không cần nhớ toàn bộ UML.

Chỉ cần thành thạo các ký hiệu sau.

Initial Node

Điểm bắt đầu của quy trình.

Có đúng một điểm bắt đầu trong mỗi luồng chính.

Activity

Một công việc hoặc hành động.

Ví dụ:

  • Nhập thông tin đăng ký.
  • Kiểm tra điều kiện.
  • Xác nhận thanh toán.
  • Cập nhật dữ liệu.

Tên Activity nên bắt đầu bằng động từ.

Decision Node

Điểm ra quyết định.

Ví dụ:

Học phần còn chỗ?

Nếu:

Có → tiếp tục đăng ký.

Không → thông báo hết chỗ.

Decision luôn đi kèm các điều kiện rõ ràng.

Merge Node

Hợp nhất các nhánh sau khi đã xử lý các điều kiện khác nhau.

Merge không có nghĩa là thực hiện đồng thời.

Nó chỉ đưa các luồng quay trở lại một dòng xử lý chung.

Fork và Join

Dùng khi có các công việc có thể thực hiện song song.

Ví dụ:

Sau khi thanh toán thành công.

Hệ thống đồng thời:

  • Gửi email xác nhận.
  • Cập nhật lịch sử giao dịch.
  • Ghi nhật ký hệ thống.

Sau khi tất cả hoàn thành.

Quy trình mới tiếp tục.

Final Node

Điểm kết thúc quy trình.

5. Swimlane – Ai thực hiện công việc?

Đây là một trong những điểm mạnh của Activity Diagram.

Ví dụ quy trình đăng ký học phần.

Có ba bên tham gia:

  • Sinh viên.
  • Hệ thống.
  • Phòng đào tạo.

Nếu không phân chia rõ.

Người đọc sẽ khó biết:

Ai chịu trách nhiệm cho từng bước?

Swimlane giúp chia quy trình theo vai trò hoặc bộ phận.

Ví dụ:

Sinh viênHệ thốngPhòng đào tạo
Chọn học phầnKiểm tra điều kiện
Xác nhận đăng kýLưu dữ liệu
Duyệt ngoại lệ

Nhờ đó, trách nhiệm của từng bên được thể hiện rõ ràng.

6. Ví dụ

Quy trình:

Đăng ký học phần.

Bắt đầu
↓
Sinh viên chọn học phần
↓
Hệ thống kiểm tra điều kiện tiên quyết
↓
Đủ điều kiện?
├── Không
│      ↓
│  Thông báo lỗi
│      ↓
│   Kết thúc
└── Có
       ↓
Kiểm tra số chỗ còn lại
↓
Còn chỗ?
├── Không
│      ↓
│ Thông báo hết chỗ
│      ↓
│ Kết thúc
└── Có
       ↓
Lưu đăng ký
↓
Cập nhật thời khóa biểu
↓
Thông báo thành công
↓
Kết thúc

Đây chính là nội dung mà Activity Diagram sẽ biểu diễn bằng ký hiệu UML.

7. Khi nào nên sử dụng Activity Diagram?

Activity Diagram đặc biệt phù hợp khi:

  • Quy trình có nhiều bước.
  • Có nhiều điều kiện rẽ nhánh.
  • Có nhiều bộ phận tham gia.
  • Muốn mô tả AS-IS hoặc TO-BE Process.
  • Muốn giải thích nghiệp vụ với stakeholder.

Nếu chỉ mô tả một thao tác đơn giản.

Có thể không cần Activity Diagram.

Sai lầm thường gặp

Vẽ giống Flowchart lập trình

Nhiều sinh viên đưa vào sơ đồ:

  • Biến.
  • Công thức.
  • Thuật toán.
  • Câu lệnh SQL.

Đây không phải mục tiêu của Activity Diagram.

Không đặt điều kiện cho Decision

Ví dụ:

◇
↓
↓

Không biết nhánh nào xảy ra trong điều kiện nào.

Mỗi nhánh nên có điều kiện rõ ràng.

Ví dụ:

  • [Còn chỗ]
  • [Hết chỗ]

Quá nhiều Activity trong một sơ đồ

Nếu sơ đồ có 80–100 Activity.

Hãy chia thành nhiều Activity Diagram nhỏ theo từng Use Case.

Không sử dụng Swimlane

Nếu có nhiều Actor hoặc nhiều phòng ban.

Swimlane giúp sơ đồ dễ đọc và phản ánh đúng trách nhiệm của từng bên.

Tóm tắt

Activity Diagram mô tả quy trình thực hiện một công việc, từ lúc bắt đầu đến khi kết thúc.

Nó giúp:

  • Hiểu quy trình nghiệp vụ.
  • Phát hiện bước dư thừa.
  • Xác định trách nhiệm của từng bên.
  • Làm cơ sở để thiết kế và kiểm thử.

Hãy nhớ:

Nếu Use Case trả lời “làm gì”, thì Activity Diagram trả lời “làm như thế nào”.

Deliverable

Chọn 03 Use Case trong hệ thống của bạn và xây dựng Activity Diagram cho mỗi Use Case.

Yêu cầu:

  • Có Initial Node và Final Node.
  • Có ít nhất 2 Decision Node.
  • Có điều kiện cho mọi nhánh quyết định.
  • Có Swimlane nếu quy trình có nhiều Actor.
  • Không mô tả chi tiết giao diện hoặc thuật toán.

Sau khi hoàn thành, hãy tự đánh giá:

  • Một stakeholder chưa biết hệ thống có hiểu được quy trình chỉ bằng sơ đồ này không?
  • Có bước nào trong sơ đồ không tạo ra giá trị và nên được loại bỏ?

Checklist

Sau khi học xong bài này, bạn nên trả lời được:

  • Activity Diagram dùng để làm gì?
  • Phân biệt Activity Diagram và Flowchart.
  • Biết ý nghĩa của Initial Node, Activity, Decision, Merge, Fork, Join và Final Node.
  • Biết sử dụng Swimlane để phân chia trách nhiệm.
  • Mô hình hóa được một quy trình nghiệp vụ bằng Activity Diagram.

Góc nhìn nghề nghiệp

Trong các dự án chuyển đổi số, Activity Diagram thường là sơ đồ được sử dụng nhiều nhất trong các buổi khảo sát và xác nhận nghiệp vụ. Khi được xây dựng tốt, sơ đồ này giúp khách hàng, chuyên gia nghiệp vụ, System Analyst, lập trình viên và kiểm thử viên cùng nhìn vào một quy trình thống nhất, từ đó giảm đáng kể hiểu nhầm trong quá trình phát triển.

Điều đáng chú ý là Activity Diagram không chỉ dùng để mô tả TO-BE Process, mà còn rất hiệu quả khi phân tích AS-IS Process. So sánh hai sơ đồ này giúp nhóm dự án nhìn rõ những bước được loại bỏ, tự động hóa hoặc bổ sung, tạo cơ sở cho việc đánh giá giá trị mà hệ thống mới mang lại.

Bài tiếp theo

Đến đây, chúng ta đã biết quy trình diễn ra theo trình tự nào. Tuy nhiên, Activity Diagram chưa cho biết các đối tượng trong hệ thống trao đổi thông tin với nhau như thế nào theo thời gian.

Trong Bài 15, chúng ta sẽ tìm hiểu Sequence Diagram. Nếu Activity Diagram trả lời “quy trình gồm những bước gì?”, thì Sequence Diagram sẽ trả lời “các đối tượng gọi nhau theo thứ tự nào để thực hiện quy trình đó?”. Đây là cầu nối quan trọng giữa phân tích yêu cầu và thiết kế phần mềm hướng đối tượng.

Comments are closed.

MENU