Hướng dẫn thực hành về UML với Visual Paradigm và VPasCode

UML (Ngôn ngữ Mô hình hóa Thống nhất) là một phương pháp chuẩn hóa để mô tả cấu trúc và hành vi của một hệ thống. Nó giúp các nhóm thảo luận về yêu cầu, thiết kế phần mềm và ghi lại các quyết định. UML là một ngôn ngữ mô hình hóa, không phải là ngôn ngữ lập trình: các biểu đồ truyền đạt một mô hình, nhưng chúng không tự động đảm bảo rằng việc triển khai khớp với mô hình đó.

Hướng dẫn này sử dụng hệ thống mua sắm trực tuyến làm ví dụ minh họa xuyên suốt. Nó bao gồm các loại biểu đồ UML chính và quy trình làm việc sử dụng Visual Paradigm cho mô hình hóa trực quan và VPasCode cho các biểu đồ dựa trên văn bản.

1. Bắt đầu bằng câu hỏi mà biểu đồ của bạn cần trả lời

Trước khi vẽ, hãy quyết định người đọc cần hiểu điều gì:

• Người dùng có thể làm được những gì? Sử dụng biểu đồ trường hợp sử dụng.

• Điều gì xảy ra trong một kịch bản? Sử dụng biểu đồ trình tự hoặc biểu đồ hoạt động.

• Những khái niệm và mối quan hệ nào tạo nên miền bài toán? Sử dụng biểu đồ lớp.

• Phần mềm được chia thành các phần có thể triển khai hoặc thay thế như thế nào? Sử dụng biểu đồ thành phần và biểu đồ triển khai.

• Một đối tượng thay đổi theo thời gian như thế nào? Sử dụng biểu đồ máy trạng thái.

Một biểu đồ cố gắng trả lời mọi câu hỏi cùng lúc thường trở nên khó đọc. Hãy ưu tiên nhiều biểu đồ tập trung thay vì một bản tổng quan quá tải.

2. Các họ biểu đồ UML

UML 2.x bao gồm 14 loại biểu đồ tiêu chuẩn, thường được nhóm thành biểu đồ cấu trúc và biểu đồ hành vi. Các biểu đồ tương tác là một tập con của các biểu đồ hành vi.

Bạn hiếm khi cần dùng đủ 14 loại biểu đồ cho một dự án. Đối với nhiều thiết kế ứng dụng, bộ biểu đồ bao gồm biểu đồ trường hợp sử dụng, lớp, trình tự, hoạt động, thành phần và triển khai là một bộ khởi đầu mạnh mẽ.

3. Các biểu đồ hữu ích nhất, với một ví dụ về thương mại điện tử

Biểu đồ trường hợp sử dụng: mục tiêu và ranh giới hệ thống

Biểu đồ trường hợp sử dụng mô tả mục tiêu của người dùng, không phải bố cục màn hình hoặc mã nội bộ. Đối với một cửa hàng trực tuyến, các vai trò có thể bao gồm Khách hàng, Nhà cung cấp thanh toán, và Dịch vụ kho hàng. Các trường hợp sử dụng có thể bao gồm Duyệt sản phẩm, Đặt hàng, Thanh toán cho đơn hàng, và Theo dõi vận chuyển.

Sử dụng <<include>>khi một trường hợp sử dụng luôn gọi một hành vi bắt buộc khác. Sử dụng <<extend>>cho hành vi tùy chọn hoặc có điều kiện bổ sung cho một trường hợp sử dụng cơ sở. Giữ ranh giới hệ thống rõ ràng để người đọc có thể phân biệt hệ thống với các vai trò bên ngoài.

Sơ đồ hoạt động: quy trình và quyết định

Sơ đồ hoạt động hữu ích cho các quy trình có nhánh hoặc công việc song song. Một luồng thanh toán có thể như sau:

1. Xác thực giỏ hàng và địa chỉ.

2. Tính phí vận chuyển và thuế.

3. Tạo đơn hàng tạm thời.

4. Yêu cầu xác thực thanh toán.

5. Nếu thanh toán thành công, xác nhận đơn hàng và thông báo cho bộ phận thực hiện.

6. Nếu thanh toán thất bại, hiển thị lỗi và giữ đơn hàng ở trạng thái chưa xác nhận.

Sử dụng các nút quyết định và hợp nhất cho các nhánh, các nút phân nhánh và hợp nhất cho công việc song song, và các làn (swimlanes) khi trách nhiệm thay đổi giữa khách hàng, cửa hàng và nhà cung cấp bên ngoài.

Sơ đồ trình tự: một kịch bản theo thời gian

Sơ đồ trình tự hiển thị các thành viên tham gia và các thông điệp họ trao đổi. Chúng đặc biệt hữu ích để làm rõ ranh giới dịch vụ, thứ tự gọi và các trường hợp lỗi. Thêm các đường dẫn thay thế cho các kết quả như từ chối thanh toán hoặc hàng hóa hết hàng.

@startuml
actor Customer
participant "Storefront" as UI
participant "Order Service" as Orders
participant "Inventory Service" as Inventory
participant "Payment Provider" as Payment

Customer -> UI: submit checkout
UI -> Orders: placeOrder(cart, address)
Orders -> Inventory: reserve(items)

alt items available
    Inventory --> Orders: reservation confirmed
    Orders -> Payment: authorize(total)
    alt payment approved
        Payment --> Orders: approved
        Orders --> UI: order confirmed
        UI --> Customer: show confirmation
    else payment declined
        Payment --> Orders: declined
        Orders -> Inventory: release reservation
        Orders --> UI: payment failed
        UI --> Customer: show payment error
    end
else items unavailable
    Inventory --> Orders: reservation failed
    Orders --> UI: item unavailable
    UI --> Customer: show availability error
end
@enduml

Ví dụ này sử dụng cú pháp PlantUML. Đây là một bản phác thảo hành vi, không phải là bản quy định chi tiết cho mọi thời gian chờ, thử lại hoặc quy tắc bảo mật. Hãy thêm các chi tiết đó khi chúng quan trọng đối với thiết kế.

Sơ đồ lớp: cấu trúc miền

Sơ đồ lớp mô tả các kiểu và mối quan hệ của chúng. Một mô hình đơn hàng nhỏ có thể bao gồm:

• Khách hàng

• Đơn hàng

• Dòng đơn hàng

• Sản phẩm

• Thanh toán

Hiển thị các thuộc tính và các phép toán khi chúng giúp giải thích trách nhiệm. Sử dụng số lượng (multiplicities) để làm rõ các quy tắc về số lượng: ví dụ, một Đơn hàng chứa một hoặc nhiều Dòng đơn hàng đối tượng, trong khi mỗi Dòng đơn hàng tham chiếu đến một Sản phẩm.

Các loại quan hệ phổ biến:

• Liên kết: một liên kết cấu trúc chung.

• Kế thừa/phổ quát hóa: một lớp là một dạng chuyên biệt của một lớp khác.

• Tụ hợp: một quan hệ toàn thể–bộ phận mà các bộ phận có thể tồn tại độc lập; hãy sử dụng một cách tiết kiệm.

• Tổ hợp: một quan hệ toàn thể–bộ phận chặt chẽ mà vòng đời của bộ phận gắn liền với toàn thể.

• Phụ thuộc: một phần tử sử dụng hoặc phụ thuộc vào một phần tử khác.

Đối với mô hình thương mại, một Dòng đơn hàng thường được mô hình hóa là thuộc về một Đơn hàng, trong khi một Sản phẩm tồn tại độc lập với bất kỳ đơn hàng cụ thể nào. Hãy chọn quan hệ phản ánh đúng vòng đời và quy tắc thực tế của miền.

Sơ đồ máy trạng thái: quy tắc vòng đời

Hãy sử dụng máy trạng thái khi các chuyển đổi được phép của đối tượng là quan trọng. Một đơn hàng có thể chuyển qua:

Chờ xử lý → Đang chờ thanh toán → Đã xác nhận → Đã hoàn tất

Nó cũng có thể chuyển sang Đã hủy hoặc Thanh toán thất bại. Gán nhãn cho các chuyển đổi bằng các sự kiện kích hoạt hoặc điều kiện bảo vệ, chẳng hạn như thanh toán được phê duyệt hoặc [stockAvailable]. Biểu đồ này có thể làm lộ các chuyển đổi không hợp lệ—ví dụ, liệu một đơn hàng đã hoàn thành có thể bị hủy hay không.

Biểu đồ thành phần và biểu đồ triển khai: phần mềm và thời gian chạy

Một biểu đồ thành phầnhiển thị các trách nhiệm và phụ thuộc của phần mềm, chẳng hạn như cửa hàng trực tuyến, dịch vụ đơn hàng, dịch vụ tồn kho và bộ chuyển đổi thanh toán. Nó hữu ích để thảo luận về tính mô-đun và ranh giới tích hợp.

Một biểu đồ triển khaihiển thị nơi phần mềm được thực thi: ví dụ, trình duyệt, môi trường chạy ứng dụng, cơ sở dữ liệu và nhà cung cấp thanh toán bên ngoài. Hãy sử dụng nó để thảo luận về cấu trúc topology thời gian chạy, không phải cấu hình mạng chi tiết.

4. Mô hình hóa tốt: các quy ước thực tiễn

• Gán cho mỗi biểu đồ một tiêu đề rõ ràng và một mục đích duy nhất.

• Sử dụng ngôn ngữ miền một cách nhất quán; tránh tạo ra các tên khác nhau cho cùng một khái niệm.

• Giữ các biểu đồ đủ nhỏ để có thể đọc được ở kích thước dự định.

• Chỉ bao gồm các chi tiết trả lời câu hỏi của biểu đồ.

• Ghi nhãn các mối liên kết quan trọng và luồng thông điệp.

• Thêm tính đa trị cho các mối liên kết khi các quy tắc về số lượng có ý nghĩa.

• Sử dụng ghi chú cho các giả định, ràng buộc và các quyết định chưa được giải quyết.

• Giữ tên và trách nhiệm nhất quán trên tất cả các biểu đồ.

• Phân biệt rõ những gì đã được xác nhận với những gì được đề xuất hoặc vẫn chưa rõ ràng.

• Cập nhật các biểu đồ khi có các quyết định thiết kế quan trọng hoặc thay đổi về hành vi.

Xem UML như một công cụ hỗ trợ giao tiếp. Một biểu đồ có thể hợp lệ về mặt cú pháp nhưng vẫn gây hiểu lầm nếu các nhãn, giả định hoặc phạm vi của nó không rõ ràng.

5. Sử dụng Visual Paradigm

Visual Paradigm phù hợp cho mô hình hóa đồ họa: tạo và sắp xếp các phần tử UML trên một bảng vẽ, tổ chức các biểu đồ liên quan và tinh chỉnh mô hình thông qua chỉnh sửa trực quan. Tài liệu sản phẩm của nó mô tả mô hình hóa UML trong số các khả năng mô hình hóa trực quan của nó.

Một quy trình làm việc thực tiễn:

1. Tạo một dự áncho hệ thống hoặc phạm vi giới hạn mà bạn đang mô hình hóa.

2. Bắt đầu với các yêu cầu và phạm vi.Xác định người dùng, các hệ thống bên ngoài và các mục tiêu chính.

3. Tạo một biểu đồ kịch bản sử dụngđể thiết lập ranh giới và các tương tác chính.

4. Thêm biểu đồ hành vicho các kịch bản mang lại rủi ro hoặc sự không rõ ràng nhiều nhất.

5. Xây dựng mô hình lớpdựa trên các khái niệm miền và các quy tắc của chúng.

6. Thêm các chế độ xem thành phần và triển khainếu kiến trúc hoặc vị trí thời gian chạy cần được thảo luận.

7. Xem xét với các bên liên quan.Kiểm tra tên, phạm vi, luồng thay thế và lực lượng.

8. Xuất hoặc chia sẻ biểu đồở các định dạng phù hợp cho việc xem xét và tài liệu hóa.

9. Giữ cho mô hình được duy trì.Chỉ định một chủ sở hữu và cập nhật các biểu đồ khi các quyết định thay đổi.

Tên menu chính xác và các tính năng có sẵn có thể thay đổi tùy theo phiên bản và bản phát hành của Visual Paradigm, vì vậy hãy sử dụng tài liệu giao diện hiện tại của sản phẩm cho các bước cụ thể theo phiên bản.

6. Sử dụng VPasCode

VPasCode là một trình soạn thảo sơ đồ dưới dạng mã dựa trên trình duyệt từ Visual Paradigm. Thông tin sản phẩm của nó mô tả hỗ trợ cho các định dạng sơ đồ dựa trên văn bản bao gồm PlantUML và Mermaid, với khả năng hiển thị trực tiếp; nó cũng mô tả các tùy chọn xuất như SVG và PNG.

Một quy trình làm việc đơn giản:

1. Mở VPasCode và chọn ngôn ngữ sơ đồ, chẳng hạn như PlantUML.

2. Viết hoặc dán một kịch bản sơ đồ.

3. Kiểm tra bản xem trước đã được hiển thị khi bạn chỉnh sửa.

4. Tinh chỉnh tên, mối quan hệ, bố cục và các đường dẫn lỗi.

5. Xuất một hình ảnh cho tài liệu hoặc xem xét.

6. Giữ lại kịch bản nguồn cùng với dự án nếu bạn muốn một bản ghi dựa trên văn bản có thể được xem xét và quản lý phiên bản.

VPasCode phù hợp cho các bản nháp nhanh, sơ đồ tài liệu và các nhóm ưa thích việc chỉnh sửa dựa trên văn bản. Mô hình đồ họa của Visual Paradigm hữu ích khi bạn muốn thao tác các phần tử mô hình một cách trực quan và tổ chức các sơ đồ như một phần của dự án mô hình hóa lớn hơn. Hai phương pháp này có thể bổ sung cho nhau, nhưng đừng giả định rằng mọi sơ đồ hoặc mô hình đều chuyển đổi qua lại giữa chúng với độ trung thực hoàn hảo; hãy xác minh mọi chuyển đổi trong quy trình làm việc của bạn.

7. Một quy trình làm việc toàn diện hữu ích

Đối với tính năng thanh toán, một chuỗi mô hình hóa nhẹ có thể là:

1. Trường hợp sử dụng:xác định ai có thể đặt hàng và các hệ thống bên ngoài nào tham gia.

2. Hoạt động:ánh xạ luồng thanh toán và các quyết định của nó.

3. Chuỗi: chi tiết các tương tác cho các luồng thành công, thất bại thanh toán và hết hàng.

4. Lớp: xác định các khái niệm về đơn hàng, dòng sản phẩm, sản phẩm và thanh toán cùng các quy tắc của chúng.

5. Máy trạng thái: xác định vòng đời đơn hàng hợp lệ.

6. Thành phần: chỉ ra dịch vụ nào chịu trách nhiệm cho các nhiệm vụ đó.

7. Triển khai: tài liệu hóa vị trí chạy thời gian thực nếu các quyết định về cơ sở hạ tầng có liên quan.

Sử dụng Visual Paradigm khi nhóm được hưởng lợi từ việc mô hình hóa dựa trên bảng vẽ và mô hình trực quan được quản lý. Sử dụng VPasCode khi nhóm muốn viết và hiển thị văn bản sơ đồ nhanh chóng. Một phương pháp phổ biến là phác thảo một kịch bản trong VPasCode, xem xét và tinh chỉnh nó cùng nhóm, sau đó duy trì các sơ đồ ở định dạng phù hợp nhất với quy trình tài liệu hóa và thay đổi của dự án.

8. Những lỗi phổ biến

• Cố gắng vẽ sơ đồ toàn bộ hệ thống cùng một lúc: chia theo mối quan tâm hoặc kịch bản.

• Nhầm lẫn giữa hoạt động và chuỗi: hoạt động nhấn mạnh quy trình làm việc; chuỗi nhấn mạnh các tin nhắn theo thời gian.

• Quá tải sơ đồ lớp: tập trung vào các khái niệm miền liên quan, không phải mọi chi tiết triển khai.

• Sử dụng include và extend như một yếu tố trang trí: chúng biểu thị các mối quan hệ cụ thể giữa các trường hợp sử dụng.

• Bỏ sót các luồng thay thế: các lỗi và hủy bỏ thường làm lộ ra các yêu cầu quan trọng.

• Xem hình ảnh như là bản đặc tả: tài liệu hóa rõ ràng các quy tắc kinh doanh, giả định và ràng buộc quan trọng.

• Để các sơ đồ bị lỗi thời: một sơ đồ lỗi thời có thể còn tệ hơn không có sơ đồ nào vì người đọc có thể tin tưởng vào nó.

Một bộ UML mạnh không phải là bộ lớn nhất. Đó là bộ sơ đồ nhỏ nhất cho phép người đọc mục tiêu hiểu hệ thống, thảo luận các quyết định và phát hiện các lỗ hổng trước khi chúng trở nên tốn kém.

This post is also available in Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, 简体中文 and 繁體中文.