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

Mô hình hóa Động lực Hệ thống – Biểu đồ Tuần tự và Biểu đồ Triển khai

4.1. Giới thiệu: Thổi hồn vào Kiến trúc

Sau khi đã xây dựng được bộ khung tĩnh cho hệ thống bằng các biểu đồ cấu trúc, một câu hỏi quan trọng vẫn còn đó: “Làm thế nào để các bộ phận này phối hợp với nhau để thực hiện một công việc hữu ích?”. Một bản thiết kế kiến trúc chỉ thực sự hoàn chỉnh khi nó có thể chứng minh được rằng các thành phần có thể tương tác một cách chính xác để đáp ứng các yêu cầu chức năng. Đây là lúc chúng ta cần mô hình hóa hành vi động của hệ thống. Biểu đồ Tuần tự (Sequence Diagram) và Biểu đồ Triển khai (Deployment Diagram) là hai công cụ chủ chốt giúp chúng ta thổi hồn vào kiến trúc, biến những cấu trúc tĩnh thành một cỗ máy hoạt động sống động.

4.2. Dàn dựng các Tương tác với Biểu đồ Tuần tự

Biểu đồ Tuần tự là một trong những biểu đồ hành vi mạnh mẽ nhất, cho thấy cách các đối tượng (hoặc các thành phần) tương tác với nhau theo một trình tự thời gian cụ thể để hoàn thành một mục tiêu hoặc một use case. Nó tập trung vào việc gửi và nhận các thông điệp giữa các đối tượng.

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

  • Đường sống (Lifeline): Một đường nét đứt thẳng đứng, đại diện cho một đối tượng hoặc một thực thể tham gia vào tương tác. Phía trên đường sống là một hình chữ nhật chứa tên của đối tượng (ví dụ: aCustomer:Customer).
  • Thanh Kích hoạt (Activation Bar): Một hình chữ nhật hẹp nằm trên đường sống, cho biết khoảng thời gian mà đối tượng đó đang bận thực hiện một hành động (đang xử lý một phương thức).
  • Thông điệp (Message): Một mũi tên đi từ đường sống này sang đường sống khác, biểu thị một lời gọi phương thức hoặc một hình thức giao tiếp.
  • Synchronous Message (Thông điệp đồng bộ): Mũi tên đặc. Người gửi sẽ đợi cho đến khi người nhận xử lý xong và trả về kết quả.
  • Asynchronous Message (Thông điệp bất đồng bộ): Mũi tên hở. Người gửi không cần chờ phản hồi và có thể tiếp tục công việc của mình.
  • Reply Message (Thông điệp trả lời): Mũi tên nét đứt, cho thấy kết quả trả về từ một thông điệp đồng bộ.
  • Mảnh Tương tác (Interaction Fragment): Các khung hình chữ nhật được sử dụng để mô hình hóa các logic phức tạp:
    • alt (Alternative): Dùng cho các luồng thay thế (tương đương if-then-else).
    • opt (Optional): Dùng cho một chuỗi các hành động chỉ xảy ra nếu một điều kiện nào đó được thỏa mãn.
    • loop: Dùng để biểu thị một chuỗi các hành động được lặp lại.

Ví dụ thực tế: Chi tiết hóa Use Case “Chuyển tiền”

Hãy tạo một Biểu đồ Tuần tự chi tiết cho use case “Chuyển tiền” trong hệ thống ngân hàng của chúng ta:

  1. Xác định các Lifeline: customer:Customer, :TransferUI (Giao diện chuyển tiền), :TransferController (Bộ điều khiển logic), sourceAccount:Account (Tài khoản nguồn), destAccount:Account (Tài khoản đích).
  2. Mô hình hóa chuỗi sự kiện:
    • customer bắt đầu tương tác bằng cách gọi phương thức initiateTransfer() trên :TransferUI.
    • :TransferUI hiển thị form, customer nhập thông tin và nhấn “Submit”.
    • :TransferUI gửi một thông điệp đồng bộ transfer(sourceAccNum, destAccNum, amount) đến :TransferController. Thanh kích hoạt của Controller bắt đầu.
    • :TransferController tìm đối tượng sourceAccount và destAccount từ cơ sở dữ liệu (có thể có một lifeline :AccountRepository).
  3. Bên trong một mảnh alt để kiểm tra số dư:
    • [Điều kiện: số dư >= số tiền chuyển] :TransferController gọi phương thức withdraw(amount) trên sourceAccount. Sau đó, nó gọi deposit(amount) trên destAccount.
    • [Điều kiện: else] :TransferController tạo một thông điệp lỗi và trả về cho :TransferUI.
    • Cuối cùng, :TransferController trả về một thông điệp thành công cho :TransferUI, và :TransferUI hiển thị thông báo cho customer.

Biểu đồ Tuần tự chính là “thí nghiệm trong tưởng tượng” của kiến trúc sư. Nó buộc họ phải chuyển từ suy nghĩ “nếu như” ở mức độ cao sang “chính xác là như thế nào” ở mức độ thấp. Quá trình vẽ một biểu đồ tuần tự là một hình thức xác thực thiết kế cực kỳ hiệu quả. Nếu bạn không thể vẽ ra chuỗi thông điệp để hoàn thành một use case, điều đó có nghĩa là thiết kế của bạn có lỗ hổng hoặc chưa hoàn chỉnh. Ví dụ, trong quá trình vẽ, SA có thể nhận ra rằng lớp Account thiếu một phương thức cần thiết, hoặc một tương tác nào đó quá “ồn ào” (quá nhiều thông điệp qua lại), có thể gây ra tắc nghẽn hiệu năng. Do đó, việc tạo ra biểu đồ này là một bài kiểm tra nghiêm ngặt đối với chính thiết kế kiến trúc, giúp phát hiện các sai sót trước khi chúng trở thành lỗi trong mã nguồn.

4.3. Từ Logic đến Thực tế: Hướng dẫn về Biểu đồ Triển khai

Sau khi đã thiết kế xong cả cấu trúc và hành vi, câu hỏi cuối cùng là: “Hệ thống này sẽ chạy ở đâu và như thế nào trong thế giới thực?”. Biểu đồ Triển khai trả lời câu hỏi này bằng cách mô hình hóa việc triển khai vật lý của các cấu phần phần mềm (artifacts) lên các nút phần cứng (nodes).

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

  • Nút (Node): Đại diện cho một tài nguyên phần cứng vật lý hoặc ảo có khả năng xử lý (ví dụ: Application Server, Database Server, thiết bị di động). Nó được biểu diễn bằng một hình hộp 3D.
  • Môi trường Thực thi (Execution Environment): Một môi trường phần mềm nằm bên trong một Node (ví dụ: Hệ điều hành, Máy ảo Java – JVM, Docker container). Nó thường được vẽ như một node lồng bên trong node khác.
  • Cấu phần (Artifact): Một sản phẩm vật lý của quá trình phát triển phần mềm (ví dụ: file .jar, .war, .exe, một script). Nó được biểu diễn bằng một hình chữ nhật với stereotype <<artifact>>.
  • Đường Truyền thông (Communication Path): Một đường thẳng nối giữa các Node, đại diện cho một kết nối mạng (ví dụ: HTTP, TCP/IP, JDBC).

Ví dụ thực tế: Ứng dụng Web dựa trên Nền tảng Đám mây

Hãy thiết kế một Biểu đồ Triển khai cho một kiến trúc đám mây hiện đại:

  1. Xác định các Node:
  • Client PC: Máy tính của người dùng.
  • Cloud Load Balancer: Bộ cân bằng tải trên đám mây.
  • Web Server Node (có thể có nhiều node): Các máy chủ web.
  • Database Server Node: Máy chủ cơ sở dữ liệu.
  • Cloud Storage Node (ví dụ: AWS S3): Dịch vụ lưu trữ file.
  1. Xác định các Artifact:
  • WebApp.war: Artifact ứng dụng web.
  • Database Schema: Artifact cho cơ sở dữ liệu.
  1. Vẽ biểu đồ và kết nối:
  • Node Client PC chứa một Web Browser (Execution Environment).
  • Client PC kết nối với Cloud Load Balancer qua đường truyền HTTPS.
  • Cloud Load Balancer phân phối lưu lượng đến nhiều Web Server Node.
  • Bên trong mỗi Web Server Node, có một Application Server (Execution Environment) và artifact WebApp.war được triển khai trên đó.
  • Web Server Node kết nối với Database Server Node qua đường truyền JDBC.
  • Database Server Node chứa một DBMS (Execution Environment) và triển khai Database Schema.
  • Web Server Node cũng kết nối với Cloud Storage Node để lưu và truy xuất file.

Biểu đồ Triển khai là nơi thiết kế trừu tượng của SA gặp gỡ với thực tế khắc nghiệt của thế giới vật lý. Đây là biểu đồ chính để lý giải và truyền đạt các giải pháp cho các yêu cầu phi chức năng (NFRs) quan trọng. Một cuộc thảo luận về khả năng mở rộng (scalability) chính là cuộc thảo luận về việc thêm các Node mới. Một cuộc thảo luận về tính sẵn sàng cao (high availability) là về các Node dự phòng và bộ cân bằng tải. Một cuộc thảo luận về bảo mật là về các tường lửa và các đường truyền thông giữa các Node. Biểu đồ này trở thành công cụ giao tiếp quan trọng giữa các kiến trúc sư phần mềm và đội ngũ hạ tầng/DevOps, cho phép họ có những cuộc thảo luận cụ thể về thông số kỹ thuật máy chủ, cấu hình mạng, quy tắc tường lửa và chiến lược triển khai.

Steve VU

,

Bình luận về bài viết này