Sử dụng UML hiệu quả cho Kiến trúc sư giải pháp – Phần 2

Định Hình Mục Đích Hệ Thống – Biểu đồ Ca Sử Dụng và Biểu đồ Hoạt Động

2.1. Giới thiệu: Từ Ý tưởng Kinh doanh đến Phạm vi Hệ thống

Bước đầu tiên và quan trọng nhất trong bất kỳ dự án thành công nào là phải định nghĩa một cách rõ ràng hệ thống sẽ làm gì. Đây là giai đoạn mà một Solution Architect phải làm việc chặt chẽ với các bên liên quan phía kinh doanh để chuyển những ý tưởng mơ hồ thành các yêu cầu cụ thể và có thể đo lường được. Trong giai đoạn này, các biểu đồ hành vi, đặc biệt là Biểu đồ Ca sử dụng (Use Case Diagram) và Biểu đồ Hoạt động (Activity Diagram), trở thành công cụ không thể thiếu để nắm bắt, tinh chỉnh và xác nhận phạm vi của dự án.

2.2. Nắm bắt Yêu cầu với Biểu đồ Ca sử dụng

Biểu đồ Ca sử dụng là một trong những công cụ giao tiếp hiệu quả nhất giữa thế giới kinh doanh và thế giới kỹ thuật. Nó cung cấp một cái nhìn tổng quan, ở mức độ cao về các chức năng của hệ thống, tập trung vào việc trả lời câu hỏi “Hệ thống làm gì?” chứ không phải “Hệ thống làm như thế nào?”.

Các thành phần cốt lõi của một Biểu đồ Ca sử dụng:

• Tác nhân (Actor): Là một người dùng, một hệ thống bên ngoài, hoặc bất cứ thứ gì tương tác với hệ thống của chúng ta để đạt được một mục tiêu nào đó. Tác nhân được biểu diễn bằng hình người que.
• Ca sử dụng (Use Case): Đại diện cho một chức năng hoặc một mục tiêu cụ thể mà tác nhân muốn thực hiện thông qua hệ thống (ví dụ: “Chuyển tiền”, “Xem lịch sử giao dịch”). Nó được biểu diễn bằng một hình elip.
• Ranh giới Hệ thống (System Boundary): Là một hình chữ nhật bao quanh tất cả các use case, có tác dụng phân định rõ ràng những gì thuộc về hệ thống và những gì nằm bên ngoài.
• Các mối quan hệ (Relationships):

• Association (Liên kết): Đường thẳng nối giữa một Actor và một Use Case, thể hiện sự tương tác giữa chúng.
• Include (<<include>>): Mối quan hệ bắt buộc. Use case A <<include>> use case B có nghĩa là để thực hiện được A, thì B phải được thực hiện. Đây là hành vi được chia sẻ và bắt buộc. Ví dụ, use case “Chuyển tiền” phải <<include>> use case “Xác thực người dùng”.
• Extend (<<extend>>): Mối quan hệ mở rộng, có điều kiện. Use case C <<extend>> use case A có nghĩa là hành vi trong C là một phần mở rộng tùy chọn của A, và nó chỉ xảy ra dưới một điều kiện nhất định. Ví dụ, use case “Hiển thị thông báo lỗi” <<extend>> use case “Đăng nhập” khi người dùng nhập sai mật khẩu.

Ví dụ thực tế: Xây dựng Biểu đồ Ca sử dụng cho Hệ thống Ngân hàng Trực tuyến

Hãy cùng xây dựng một biểu đồ ca sử dụng cho hệ thống ngân hàng trực tuyến của chúng ta theo các bước sau:

1. Xác định các Tác nhân (Actors): Ai sẽ tương tác với hệ thống?

• Khách hàng (Customer)
• Nhân viên Ngân hàng (Bank Employee)
• Quản trị viên Hệ thống (System Administrator)

2. Xác định các Ca sử dụng (Use Cases): Các tác nhân muốn làm gì với hệ thống?

• Khách hàng: Đăng nhập, Xem số dư tài khoản, Chuyển tiền, Xem lịch sử giao dịch, Quản lý người thụ hưởng.
• Nhân viên Ngân hàng: Mở tài khoản cho khách hàng, Xử lý yêu cầu vay vốn.
• Quản trị viên: Quản lý người dùng, Xem nhật ký hệ thống.

3. Vẽ biểu đồ và xác định quan hệ: Kết nối các tác nhân với các use case tương ứng. Chúng ta có thể thấy rằng các use case như “Chuyển tiền” và “Xem số dư” đều yêu cầu người dùng phải đăng nhập trước. Thay vì vẽ đường nối từ “Khách hàng” đến “Đăng nhập” rồi mới đến các use case kia, chúng ta có thể sử dụng quan hệ <<include>>. Các use case “Chuyển tiền”, “Xem số dư”, “Xem lịch sử giao dịch” sẽ <<include>> use case “Xác thực người dùng”.

Mặc dù có vai trò kỹ thuật, sức mạnh thực sự của Biểu đồ Ca sử dụng đối với một SA lại nằm ở khía cạnh quản lý và giao tiếp. Nó là một trong những công cụ “chính trị” hiệu quả nhất. Các dự án thường thất bại do “scope creep” – sự phình to không kiểm soát của các yêu cầu. Điều này xảy ra khi các yêu cầu ban đầu không rõ ràng. Biểu đồ Ca sử dụng, với sự đơn giản của nó, là công cụ hoàn hảo để các bên liên quan phi kỹ thuật có thể hiểu và xác nhận. Khi một SA trình bày biểu đồ này và nhận được sự đồng thuận, nó không chỉ là một tài liệu kỹ thuật mà còn trở thành một “hợp đồng” về phạm vi. Bất kỳ yêu cầu mới nào sau này đều có thể được đối chiếu một cách khách quan với biểu đồ đã được thống nhất, giúp SA kiểm soát phạm vi dự án một cách hiệu quả.

2.3. Vạch ra Luồng công việc với Biểu đồ Hoạt động

Nếu Biểu đồ Ca sử dụng cho chúng ta biết cái gì, thì Biểu đồ Hoạt động sẽ đi sâu hơn để mô tả luồng công việc bên trong một use case. Nó giống như một sơ đồ luồng (flowchart) được nâng cấp, có khả năng mô hình hóa các quy trình nghiệp vụ phức tạp, các luồng điều khiển, các quyết định và các hoạt động song song.

Các thành phần cốt lõi của một Biểu đồ Hoạt động:

• Hành động/Hoạt động (Action/Activity): Một bước đơn lẻ trong luồng công việc, được biểu diễn bằng hình chữ nhật bo góc.
• Nút Bắt đầu/Kết thúc (Start/End Nodes): Biểu thị điểm bắt đầu (hình tròn đen) và kết thúc (hình tròn đen có viền trắng) của một luồng.
• Luồng Điều khiển (Control Flow): Mũi tên chỉ hướng di chuyển từ hoạt động này sang hoạt động tiếp theo.
• Nút Quyết định/Hợp nhất (Decision/Merge Nodes): Hình thoi đại diện cho một điểm rẽ nhánh (ví dụ: câu lệnh if-else). Các luồng sau đó có thể được hợp nhất lại cũng tại một nút hình thoi.
• Nút Phân nhánh/Kết hợp (Fork/Join Nodes): Thanh ngang dùng để tách một luồng thành nhiều luồng chạy song song (fork) và sau đó kết hợp chúng lại (join).
• Làn bơi (Swimlanes/Partitions): Các cột dọc hoặc ngang dùng để phân chia các hoạt động theo trách nhiệm của từng tác nhân hoặc thành phần hệ thống. Đây là một tính năng cực kỳ hữu ích để làm rõ “ai làm gì”.

Ví dụ thực tế: Mô hình hóa luồng “Rút tiền tại ATM”

Hãy chi tiết hóa quy trình này bằng một Biểu đồ Hoạt động:

1. Xác định các Làn bơi (Swimlanes): Chúng ta có 3 bên tham gia chính: Khách hàng (Customer), Máy ATM (ATM), và Hệ thống Ngân hàng (Bank System).
2. Mô hình hóa Luồng công việc:

• Luồng bắt đầu tại làn bơi của Khách hàng với hành động “Đưa thẻ vào máy”.
• Chuyển sang làn bơi của ATM, máy ATM thực hiện “Đọc thông tin thẻ” và “Yêu cầu nhập mã PIN”.
• Khách hàng “Nhập mã PIN”.
• ATM gửi yêu cầu “Xác thực PIN” đến Hệ thống Ngân hàng.
• Tại làn bơi của Hệ thống Ngân hàng, có một Nút Quyết định: “Mã PIN hợp lệ?”.
• Nếu không, luồng đi đến hành động “Gửi thông báo lỗi” tới ATM, ATM “Trả thẻ” và luồng kết thúc.
• Nếu có, luồng tiếp tục. Hệ thống Ngân hàng “Gửi tín hiệu thành công” tới ATM.
• ATM “Hiển thị các tùy chọn” (Rút tiền, Xem số dư, v.v.).
• Khách hàng “Chọn Rút tiền” và “Nhập số tiền”.
• ATM gửi yêu cầu “Kiểm tra số dư” đến Hệ thống Ngân hàng.
• … và cứ thế tiếp tục cho đến khi tiền được đưa ra và giao dịch kết thúc.

Đối với một SA, Biểu đồ Hoạt động không chỉ dùng để ghi lại một quy trình. Nó là một công cụ phân tích và tối ưu hóa mạnh mẽ. Khi một SA lập bản đồ quy trình nghiệp vụ “hiện tại” (as-is) bằng Biểu đồ Hoạt động với các làn bơi, họ có thể dễ dàng nhận ra các điểm yếu: các bước thừa, các nút thắt cổ chai, hoặc các công đoạn thủ công có thể được tự động hóa.⁶ Ví dụ, tại sao một yêu cầu phê duyệt phải đi qua ba người một cách tuần tự? Liệu có thể thực hiện song song không? Tại sao nhân viên phải nhập dữ liệu thủ công trong khi có thể dùng API? Từ đó, SA có thể thiết kế một Biểu đồ Hoạt động “tương lai” (to-be) tối ưu hơn. Việc so sánh hai biểu đồ trực quan này là một cách thuyết phục hơn nhiều để chứng minh giá trị của một giải pháp kiến trúc mới, thay vì chỉ trình bày bằng văn bản. Nó chuyển cuộc trò chuyện từ “xây dựng một tính năng” thành “cải thiện hiệu quả kinh doanh”.