Ngôn ngữ Mô hình Thống nhất (UML): Hướng dẫn Toàn diện về Biểu đồ, Khái niệm và Visual Paradigm

Giới thiệu

Ngôn ngữ Mô hình Thống nhất (UML) là một ngôn ngữ mô hình hóa trực quan được chuẩn hóa, được sử dụng để phân tích, thiết kế, tài liệu hóa và truyền đạt cấu trúc cũng như hành vi của các hệ thống phần mềm. Nó cung cấp một bộ ký hiệu và kỹ thuật vẽ biểu đồ chung, giúp các nhà phát triển, kiến trúc sư, nhà phân tích kinh doanh, quản lý dự án và các bên liên quan khác hiểu được cách một hệ thống hoạt động.

UML không phải là ngôn ngữ lập trình. Thay vào đó, nó đóng vai trò như một bản vẽ thiết kế trực quan cho phần mềm. Các nhóm có thể sử dụng biểu đồ UML để mô tả các yêu cầu, lập kế hoạch kiến trúc hệ thống, mô hình hóa quy trình kinh doanh, tài liệu hóa các ứng dụng hiện có và giải thích cách các phần khác nhau của một hệ thống tương tác với nhau.

Ví dụ, một ứng dụng thương mại điện tử có thể bao gồm người dùng, sản phẩm, giỏ hàng, đơn hàng, dịch vụ thanh toán và dịch vụ giao hàng. Biểu đồ UML có thể biểu diễn các yếu tố này, thể hiện mối quan hệ giữa chúng và minh họa những gì xảy ra khi một khách hàng đặt hàng.

UML được quản lý như một tiêu chuẩn ngành bởi Nhóm Quản lý Đối tượng (OMG) và cũng đã được thông qua thông qua các tiêu chuẩn quốc tế. UML hiện đại thường đề cập đến UML 2.x, định nghĩa một bộ sưu tập rộng lớn các biểu đồ cấu trúc và hành vi. Ví dụ, UML 2.2 đã định nghĩa 14 loại biểu đồ được chia đều giữa mô hình hóa cấu trúc và mô hình hóa hành vi.

UML là gì?

UML là một ngôn ngữ mô hình hóa đa năng dành cho các hệ thống tập trung vào phần mềm. Nó cung cấp một ký hiệu được chuẩn hóa để biểu diễn:

Các thành phần hệ thống
Lớp và đối tượng
Yêu cầu của người dùng
Luồng công việc và quy trình kinh doanh
Các thông điệp được trao đổi giữa các đối tượng
Trạng thái và chuyển đổi hệ thống
Môi trường triển khai phần mềm
Mối phụ thuộc giữa các gói và thành phần

Mục đích của UML không phải là thay thế mã nguồn. Thay vào đó, nó giúp các nhóm suy nghĩ và truyền đạt về một hệ thống trước, trong và sau khi triển khai.

Một mô hình UML có thể được tạo ra ở các mức độ chi tiết khác nhau:

Mức độ khái niệm:Mô tả các khái niệm kinh doanh chính mà không có chi tiết triển khai.
Mức độ phân tích:Khám phá các yêu cầu, trách nhiệm và hành vi của hệ thống.
Mức độ thiết kế:Định nghĩa các lớp, giao diện, thành phần và tương tác.
Mức độ triển khai:Đại diện cho các chi tiết tương ứng chặt chẽ với mã nguồn và cơ sở hạ tầng triển khai.

Tại sao UML lại quan trọng?

UMLcó ích vì các hệ thống phần mềm có thể trở nên khó hiểu khi chỉ được mô tả thông qua mã nguồn hoặc các tài liệu văn bản dài dòng.

Đơn giản hóa các hệ thống phức tạp

Các biểu đồ cung cấp cái nhìn tổng quan trực quan về các hệ thống lớn. Ví dụ, một biểu đồ lớp có thể hiển thị hàng chục lớp và mối quan hệ của chúng rõ ràng hơn nhiều trang văn bản.

Cải thiện giao tiếp

Các nhà phát triển, nhà thiết kế, kiến trúc sư, người kiểm thử, nhà phân tích kinh doanh và khách hàng có thể có nền tảng kỹ thuật khác nhau. UML cung cấp cho họ một ngôn ngữ trực quan chung để thảo luận về các yêu cầu và quyết định thiết kế hệ thống.

Hỗ trợ lập kế hoạch

Các nhóm có thể mô hình hóa quy trình làm việc, các lớp, dịch vụ và môi trường triển khai trước khi viết mã. Điều này có thể phát hiện các yêu cầu bị thiếu, trách nhiệm trùng lặp và các vấn đề kiến trúc ở giai đoạn đầu.

Giúp tài liệu hóa phần mềm

Biểu đồ UML có thể đóng vai trò là tài liệu kỹ thuật dài hạn. Chúng giúp các nhà phát triển mới hiểu hệ thống hiện có và hỗ trợ các nhóm bảo trì khi cần thay đổi.

Khuyến khích thiết kế tốt hơn

Việc tạo mô hình buộc một nhóm phải xem xét các câu hỏi như:

Đối tượng nào chịu trách nhiệm cho một tác vụ?
Các thành phần được kết nối như thế nào?
Điều gì xảy ra khi một thao tác thất bại?
Những lớp nào phụ thuộc lẫn nhau?
Hệ thống phản hồi như thế nào với các sự kiện khác nhau?

Các khái niệm UML cốt lõi

Lớp

Một lớp là bản thiết kế xác định các thuộc tính và các thao tác được chia sẻ bởi một nhóm đối tượng.

Ví dụ, một Đơn hàng lớp có thể chứa:

Thuộc tính: orderId, orderDate, và trạng thái
Các thao tác: calculateTotal() và cancelOrder()

Đối tượng

Một đối tượng là một thể hiện thực tế của một lớp. Nếu Đơn hàng là một lớp, order1001 có thể là một đối tượng cụ thể được tạo ra từ lớp đó.

Thuộc tính

Một thuộc tính đại diện cho dữ liệu được lưu trữ bởi một lớp hoặc đối tượng.

Ví dụ bao gồm:

tên
giá
emailAddress
trạng thái đơn hàng

Thao tác

Một thao tác đại diện cho hành vi được cung cấp bởi một lớp. Các thao tác thường được triển khai dưới dạng các phương thức trong các ngôn ngữ lập trình.

Ví dụ bao gồm:

addItem()
submitPayment()
sendNotification()

Người tham gia

Người tham gia là một vai trò bên ngoài tương tác với hệ thống. Người tham gia có thể là một người, một hệ thống khác hoặc một thiết bị bên ngoài.

Ví dụ bao gồm:

Khách hàng
Quản trị viên
Cổng thanh toán
Hệ thống kho

Giao diện

Giao diện xác định một tập hợp các hoạt động mà một lớp hoặc thành phần hứa sẽ cung cấp. Giao diện giúp giảm thiểu sự phụ thuộc và hỗ trợ các triển khai có thể thay thế cho nhau.

Mối quan hệ

Mối quan hệ mô tả cách các phần tử UML được kết nối. Các mối quan hệ phổ biến bao gồm: liên kết, phụ thuộc, tổng quát hóa, tập hợp và hợp thành.

Bội số

Bội số xác định số lượng đối tượng có thể tham gia vào một mối quan hệ.

Các ví dụ phổ biến bao gồm:

1: Chính xác một
0..1: Không hoặc một
*: Nhiều
1..*: Một hoặc nhiều
0..*: Không hoặc nhiều

Ví dụ, một khách hàng có thể đặt không hoặc nhiều đơn hàng. Điều này có thể được biểu diễn như sau:

Khách hàng 1 -------- 0..* Đơn hàng

Phân loại biểu đồ UML

Biểu đồ UMLthường được chia thành hai nhóm chính:

Biểu đồ cấu trúc
Biểu đồ hành vi

Biểu đồ cấu trúc mô tả hệ thống được tạo thành từ những gì. Biểu đồ hành vi mô tả hệ thống làm gì và cách nó hoạt động theo thời gian.

Biểu đồ UML cấu trúc

Biểu đồ cấu trúc biểu thị tổ chức tĩnh của một hệ thống. Chúng tập trung vào các lớp, đối tượng, thành phần, gói, nút và các mối quan hệ.

1. Biểu đồ lớp

Biểu đồ lớp là một trong những biểu đồ UML được sử dụng rộng rãi nhất. Nó biểu thị cấu trúc tĩnh của một hệ thống bằng cách hiển thị:

Lớp
Thuộc tính
Phép toán
Giao diện
Mối quan hệ
Độ hiển thị
Bội số

Một mô hình lớp thương mại điện tử đơn giản hóa có thể trông như sau:

Khách hàng
- customerId
- name
+ placeOrder()

Đơn hàng
- orderId
- orderDate
- status
+ calculateTotal()

Sản phẩm
- productId
- name
- price
+ updatePrice()

Các mối quan hệ có thể bao gồm:

Khách hàng 1 -------- 0..* Đơn hàng
Đơn hàng 1 -------- 1..* Sản phẩm

Trong một thiết kế chi tiết hơn, một Mục đơn hàng lớp có thể được giới thiệu giữa Đơn hàng và Sản phẩm.

Sơ đồ lớp hữu ích cho:

Mô hình hóa miền
Thiết kế hướng đối tượng
Lập kế hoạch cơ sở dữ liệu và ứng dụng
Xác định trách nhiệm
Giải thích kế thừa và giao diện

Biểu đồ lớp mô tả các lớp nói chung, trong khi biểu đồ đối tượng hiển thị các thể hiện cụ thể của các lớp đó. Visual Paradigm mô tả biểu đồ lớp là các mô hình của các lớp, thuộc tính, hoạt động và mối quan hệ trong một hệ thống hướng đối tượng.

2. Biểu đồ đối tượng

Biểu đồ đối tượng hiển thị một bức ảnh chụp nhanh của hệ thống tại một thời điểm cụ thể. Nó đại diện cho các thể hiện đối tượng thực tế thay vì các lớp chung.

Ví dụ:

customerA:Customer
name = "Alex"

order1001:Order
status = "Đã thanh toán"

Biểu đồ đối tượng hữu ích khi bạn cần minh họa:

Trạng thái của các đối tượng tại thời điểm chạy
Các mối quan hệ dữ liệu ví dụ
Một kịch bản cụ thể
Các thể hiện của các lớp được kết nối như thế nào

Biểu đồ lớp có thể cho thấy một khách hàng có thể đặt nhiều đơn hàng. Một biểu đồ đối tượng có thể cho thấy rằng customerA hiện đang sở hữu order1001 và order1002.

3. Biểu đồ thành phần

Biểu đồ thành phần thể hiện tổ chức và các phụ thuộc của các thành phần phần mềm có thể thay thế.

Một biểu đồ thành phần thương mại điện tử có thể bao gồm:

Ứng dụng Web
Dịch vụ Đặt hàng
Dịch vụ Sản phẩm
Dịch vụ Thanh toán
Dịch vụ Thông báo
Cơ sở dữ liệu

Ví dụ:

Ứng dụng Web --> Dịch vụ Đặt hàng
Dịch vụ Đặt hàng --> Dịch vụ Thanh toán
Dịch vụ Đặt hàng --> Dịch vụ Thông báo
Dịch vụ Đặt hàng --> Cơ sở dữ liệu Đặt hàng

Biểu đồ thành phần đặc biệt hữu ích cho:

Kiến trúc vi dịch vụ
Hệ thống định hướng dịch vụ
Thiết kế API
Kiến trúc ứng dụng
Hiển thị ranh giới và các phụ thuộc của dịch vụ

4. Biểu đồ triển khai

Biểu đồ triển khai biểu diễn môi trường vật lý hoặc ảo nơi phần mềm được thực thi.

Nó có thể hiển thị:

Thiết bị khách hàng
Máy chủ web
Máy chủ ứng dụng
Máy chủ cơ sở dữ liệu
Nút đám mây
Container
Kết nối mạng
Tài sản phần mềm đã triển khai

Ví dụ:

Thiết bị khách hàng
       |
       v
Máy chủ web
       |
       v
Máy chủ ứng dụng
       |
       v
Máy chủ cơ sở dữ liệu

Sơ đồ triển khai giúp các kiến trúc sư hiểu phần mềm chạy ở đâu và các thành phần cơ sở hạ tầng giao tiếp với nhau như thế nào.

5. Sơ đồ gói

Sơ đồ gói tổ chức các phần tử mô hình liên quan thành các gói và hiển thị các phụ thuộc giữa các gói đó.

Một dự án có thể chứa các gói như:

người dùng
danh mục
đơn hàng
thanh toán
thông báo

Ví dụ:

order --> user
order --> catalog
order --> payment
payment --> notification

Sơ đồ gói hữu ích cho việc:

Tổ chức các mô hình lớn
Hiển thị các phụ thuộc giữa các mô-đun
Xác định các lớp kiến trúc
Ngăn ngừa sự ghép nối không mong muốn

6. Sơ đồ cấu trúc tổng hợp

Sơ đồ cấu trúc tổng hợp hiển thị cấu trúc bên trong của một lớp, thành phần hoặc bộ phân loại có cấu trúc khác.

Nó có thể hiển thị:

Các bộ phận bên trong
Các cổng
Các bộ kết nối
Các cộng tác bên trong
Mối quan hệ giữa các phần tử bên trong

Ví dụ, một OrderController có thể chứa hoặc kết nối với:

OrderService
OrderRepository
Dịch vụ Thanh toán
Dịch vụ Thông báo

Khác với sơ đồ thành phần, thường tập trung vào các thành phần cấp cao, sơ đồ cấu trúc tổng hợp lại tập trung vào tổ chức nội bộ của một phân loại.

7. Sơ đồ Hồ sơ

Sơ đồ hồ sơ mở rộng UML cho một lĩnh vực hoặc công nghệ cụ thể. Nó định nghĩa các phần tử mô hình hóa chuyên biệt thông qua các biệt danh, giá trị gắn thẻ và các ràng buộc.

Ví dụ, một hồ sơ có thể giới thiệu các biệt danh như:

<<thực thể>>
<<bộ điều khiển>>
<<dịch vụ>>
<<vi dịch vụ>>

Sơ đồ hồ sơ hữu ích khi ký hiệu UML tiêu chuẩn cần được điều chỉnh cho:

Ứng dụng Web
Kiến trúc doanh nghiệp
Hệ thống thời gian thực
Hệ thống nhúng
Các khung lập trình cụ thể
Mô hình hóa theo ngành

Sơ đồ hồ sơ thường bị bỏ qua trong các danh sách giới thiệu, nhưng nó được bao gồm trong các loại sơ đồ tiêu chuẩn của UML 2.x. UML 2.x thường được mô tả là có bảy loại sơ đồ cấu trúc và bảy loại sơ đồ hành vi.

Sơ đồ Hành vi UML

Sơ đồ hành vi mô tả hành vi động của một hệ thống. Chúng hiển thị quy trình làm việc, sự kiện, tương tác, thay đổi trạng thái và phản hồi.

1. Sơ đồ Trường hợp sử dụng

Sơ đồ trường hợp sử dụng trình bày các yêu cầu chức năng của một hệ thống từ góc độ của các tác nhân bên ngoài.

Một hệ thống mua sắm trực tuyến điển hình có thể bao gồm các tác nhân sau:

Khách hàng
Quản trị viên
Cổng thanh toán
Dịch vụ giao hàng

Các trường hợp sử dụng có thể bao gồm:

Đăng ký tài khoản
Đăng nhập
Duyệt sản phẩm
Thêm sản phẩm vào giỏ hàng
Đặt hàng
Thanh toán
Theo dõi giao hàng
Quản lý sản phẩm

Biểu đồ trường hợp sử dụng cung cấp cái nhìn tổng quan về những gì hệ thống thực hiện mà không mô tả chi tiết triển khai.

Các mối quan hệ quan trọng bao gồm:

Liên kết:Kết nối một tác nhân với một trường hợp sử dụng.
Bao gồm:Hiển thị hành vi luôn được tái sử dụng bởi một trường hợp sử dụng khác.
Mở rộng:Hiển thị hành vi tùy chọn hoặc có điều kiện.
Tổng quát hóa:Hiển thị sự chuyên biệt hóa giữa các vai trò hoặc các trường hợp sử dụng.

Ví dụ, Đặt hàngcó thể bao gồm Thanh toán, trong khi Áp dụng giảm giácó thể mở rộng Đặt hàng.

2. Biểu đồ hoạt động

Biểu đồ hoạt động biểu diễn luồng điều khiển trong một quy trình hoặc trường hợp sử dụng. Nó hữu ích cho việc mô hình hóa các quy trình làm việc tuần tự và đồng thời.

Ví dụ: đặt hàng

Bắt đầu
  |
Duyệt sản phẩm
  |
Thêm sản phẩm vào giỏ hàng
  |
Tiến hành thanh toán
  |
Nhập thông tin thanh toán
  |
Thanh toán thành công?
 /              
Không            Có
|                |
Hiển thị lỗi     Tạo đơn hàng
                  |
              Gửi xác nhận
                  |
                 Kết thúc

Biểu đồ hoạt động có thể biểu diễn:

Các hành động
Các quyết định
Các hợp nhất
Vòng lặp
Hoạt động song song
Nút bắt đầu và kết thúc
Kênh bơi cho trách nhiệm

Kênh bơi có thể hiển thị diễn viên hoặc thành phần hệ thống nào thực hiện mỗi hành động. Ví dụ, một kênh có thể đại diện cho khách hàng, kênh khác cho dịch vụ đơn hàng, và kênh khác cho cổng thanh toán.

3. Biểu đồ trình tự

Biểu đồ trình tự hiển thị cách các đối tượng hoặc thành phần giao tiếp theo một trình tự có thứ tự thời gian.

Ví dụ: đặt hàng

Khách hàng -> WebApp: Gửi đơn hàng
WebApp -> OrderService: createOrder()
OrderService -> PaymentService: authorizePayment()
PaymentService --> OrderService: paymentApproved
OrderService -> NotificationService: sendConfirmation()
OrderService --> WebApp: orderCreated
WebApp --> Khách hàng: Hiển thị xác nhận

Biểu đồ trình tự bao gồm:

Người tham gia
Đường sự sống
Tin nhắn
Thanh kích hoạt
Tin nhắn trả về
Điều kiện
Vòng lặp
Phương án thay thế
Tương tác song song

Chúng đặc biệt hữu ích để giải thích các cuộc gọi API, tương tác dịch vụ, luồng xác thực và xử lý lỗi.

4. Biểu đồ truyền thông

Biểu đồ truyền thông, trong quá khứ được gọi là biểu đồ hợp tác trong các phiên bản UML cũ hơn, nhấn mạnh vào mối quan hệ giữa các đối tượng và các thông điệp được trao đổi giữa chúng.

Thay vì tập trung chủ yếu vào một dòng thời gian theo chiều dọc như biểu đồ trình tự, nó tập trung vào:

Các đối tượng
Các liên kết giữa các đối tượng
Các thông điệp được đánh số
Cấu trúc hợp tác

Ví dụ:

1: submitOrder()
Khách hàng ----------------> WebApp

2: createOrder()
WebApp ------------------> Dịch vụ Đơn hàng

3: authorizePayment()
Dịch vụ Đơn hàng -------------> Dịch vụ Thanh toán

Biểu đồ truyền thông hữu ích khi cấu trúc hợp tác giữa các đối tượng quan trọng hơn so với dòng thời gian trực quan chính xác.

5. Biểu đồ máy trạng thái

Biểu đồ máy trạng thái cho thấy một đối tượng hoặc hệ thống thay đổi trạng thái như thế nào để phản ứng với các sự kiện.

Một đơn hàng có thể chuyển qua các trạng thái sau:

Mới -> Chờ thanh toán -> Đã thanh toán -> Đã giao hàng -> Đã giao
                  |
                  v
              Đã hủy

Một chuyển tiếp có thể được gắn nhãn bằng một sự kiện hoặc điều kiện:

Chờ thanh toán -- paymentApproved --> Đã thanh toán
Chờ thanh toán -- paymentFailed --> Thanh toán thất bại

Biểu đồ máy trạng thái hữu ích cho:

Vòng đời đơn hàng
Trạng thái tài khoản người dùng
Trạng thái quy trình làm việc
Hành vi của thiết bị
Trạng thái kết nối mạng
Quy trình phê duyệt

Chúng đặc biệt có giá trị khi hành vi của một đối tượng phụ thuộc nhiều vào trạng thái hiện tại của nó.

6. Biểu đồ thời gian

Biểu đồ thời gian minh họa cách trạng thái hoặc giá trị của một hoặc nhiều phần tử thay đổi theo thời gian.

Nó thường được sử dụng cho:

Hệ thống thời gian thực
Hệ thống nhúng
Giao thức truyền thông
Phối hợp phần cứng và phần mềm
Tương tác nhạy cảm về hiệu suất

Ví dụ, một biểu đồ thời gian có thể hiển thị mối quan hệ giữa:

Tín hiệu của thiết bị
Trạng thái của bộ điều khiển
Giá trị cảm biến
Phản hồi trong một khoảng thời gian xác định

7. Biểu đồ tổng quan tương tác

Biểu đồ tổng quan tương tác cung cấp cái nhìn tổng quan về các tương tác bằng cách kết hợp luồng điều khiển theo kiểu hoạt động với các biểu đồ tương tác.

Nó có thể hiển thị:

Thứ tự các tương tác chính
Các quyết định giữa các mảnh tương tác
Các đường dẫn tương tác song song
Tham chiếu đến biểu đồ trình tự hoặc biểu đồ truyền thông

Ví dụ, một bản tóm tắt tương tác cho đơn hàng trực tuyến có thể kết nối:

Xác thực khách hàng
Chọn sản phẩm
Tương tác thanh toán
Xác thực thanh toán
Thực hiện đơn hàng

Biểu đồ này hữu ích khi một quy trình quá phức tạp để giải thích bằng một biểu đồ trình tự.

Mối quan hệ UML

Hiểu rõ các mối quan hệ UML là điều cần thiết để tạo ra các biểu đồ có ý nghĩa.

Liên kết

Một liên kết biểu thị mối kết nối cấu trúc giữa hai phần tử.

Khách hàng -------- Đơn hàng

Điều này cho thấy khách hàng và đơn hàng có mối liên hệ với nhau.

Liên kết có hướng

Một liên kết có hướng cho thấy khả năng điều hướng theo một chiều.

Đơn hàng ------> Thanh toán

Điều này gợi ý rằng một đơn hàng biết đến hoặc sử dụng một đối tượng thanh toán, trong khi điều ngược lại có thể không đúng.

Tổng quát hóa

Tổng quát hóa biểu diễn sự thừa kế hoặc chuyên biệt hóa.

       Người dùng
      /    
Khách hàng  Quản trị viên

Ở đây, Khách hàng và Quản trị viên là các loại chuyên biệt của Người dùng.

Phụ thuộc

Sự phụ thuộc cho thấy một phần tử tạm thời sử dụng hoặc dựa vào một phần tử khác.

OrderService - - - -> PaymentGateway

Một thay đổi đối với cổng thanh toán có thể ảnh hưởng đến dịch vụ đơn hàng.

Tập hợp

Tập hợp biểu diễn mối quan hệ giữa toàn thể và bộ phận, trong đó các bộ phận có thể tồn tại độc lập.

Đội ◇------ Cầu thủ

Một cầu thủ có thể tiếp tục tồn tại ngay cả khi đội bị giải thể.

Sáng tạo

Mối quan hệ tổng thể-phần tử biểu thị một sự phụ thuộc mạnh mẽ. Các phần tử thường phụ thuộc vào tổng thể cho vòng đời của chúng.

Đơn hàng ◆------ Mục đơn hàng

Một Mục đơn hàngcó thể được coi là một phần của đơn hàng và có thể không có ý nghĩa bên ngoài đơn hàng đó.

Thực hiện

Thực hiện chỉ ra rằng một lớp hoặc thành phần triển khai một giao diện.

Dịch vụ thanh toán - - -|> Bộ xử lý thanh toán

Dịch vụ thanh toáncung cấp hành vi được định nghĩa bởi giao diện bộ xử lý thanh toán.

Ví dụ UML: Hệ thống mua sắm trực tuyến

Hãy xem xét một ứng dụng mua sắm trực tuyến.

Các vai trò chính

Khách hàng
Quản trị viên
Cổng thanh toán
Dịch vụ giao hàng

Các trường hợp sử dụng chính

Tạo tài khoản
Duyệt sản phẩm
Thêm mục vào giỏ hàng
Đặt hàng
Thanh toán
Theo dõi giao hàng
Quản lý tồn kho

Các lớp có thể có

Khách hàng
Sản phẩm
Giỏ hàng
Mục giỏ hàng
Đơn hàng
Mục đơn hàng
Thanh toán
Giao hàng

Các thành phần dịch vụ có thể có

Dịch vụ người dùng
Dịch vụ danh mục
Dịch vụ giỏ hàng
Dịch vụ đơn hàng
Dịch vụ thanh toán
Dịch vụ vận chuyển
Dịch vụ thông báo

Ví dụ về tương tác

Khi một khách hàng đặt hàng:

Khách hàng gửi giỏ hàng.
Ứng dụng web gửi yêu cầu đến dịch vụ đơn hàng.
Dịch vụ đơn hàng xác thực các mục.
Dịch vụ thanh toán phê duyệt thanh toán.
Đơn hàng được lưu.
Dịch vụ vận chuyển được thông báo.
Dịch vụ thông báo gửi một email xác nhận.

Quy trình kinh doanh đơn lẻ này có thể được biểu diễn qua nhiều sơ đồ UML:

Sơ đồ trường hợp sử dụng: Cho thấy khách hàng có thể đặt hàng.
Sơ đồ hoạt động: Cho thấy quy trình làm việc và các điểm ra quyết định.
Sơ đồ trình tự: Cho thấy các thông điệp giữa các dịch vụ.
Sơ đồ lớp: Hiển thị Khách hàng, Đơn hàng, Sản phẩm, và các lớp liên quan.
Sơ đồ thành phần: Cho thấy các dịch vụ liên quan.
Sơ đồ triển khai: Cho thấy nơi các dịch vụ đó được thực thi.

Cách chọn sơ đồ UML phù hợp

Mục tiêu mô hình hóa	Sơ đồ UML được khuyến nghị
Hiển thị các lớp và mối quan hệ của chúng	Sơ đồ lớp
Hiển thị các thể hiện đối tượng thực tế	Sơ đồ đối tượng
Mô tả chức năng hệ thống	Sơ đồ trường hợp sử dụng
Mô hình hóa quy trình nghiệp vụ hoặc hệ thống	Sơ đồ hoạt động
Hiển thị các tin nhắn được trao đổi theo thời gian	Sơ đồ trình tự
Hiển thị sự cộng tác của các đối tượng	Sơ đồ truyền thông
Hiển thị vòng đời và các thay đổi trạng thái	Sơ đồ máy trạng thái
Hiển thị các mô-đun hoặc dịch vụ phần mềm	Sơ đồ thành phần
Hiển thị triển khai vật lý	Sơ đồ triển khai
Tổ chức các phần tử mô hình	Sơ đồ gói
Hiển thị các phần bên trong của một phân loại	Sơ đồ cấu trúc tổng hợp
Hiển thị các thay đổi theo thời gian	Sơ đồ thời gian
Tóm tắt một số tương tác	Sơ đồ tổng quan tương tác
Mở rộng UML cho một lĩnh vực chuyên biệt	Sơ hồ sơ

Một thực hành mô hình hóa tốt là chỉ chọn những sơ đồ trả lời một câu hỏi cụ thể. Tạo ra mọi sơ đồ UML có thể có có thể làm cho tài liệu trở nên phức tạp không cần thiết.

UML và Vòng đời Phát triển Phần mềm

UML có thể hỗ trợ nhiều giai đoạn của phát triển phần mềm.

Phân tích yêu cầu

Sơ đồ trường hợp sử dụng giúp xác định các vai trò và chức năng hệ thống. Sơ đồ hoạt động có thể làm rõ các quy trình kinh doanh và luồng công việc.

Phân tích hệ thống

Sơ đồ lớp có thể biểu diễn các khái niệm miền. Sơ đồ trình tự có thể giúp các nhà phân tích hiểu cách các trường hợp sử dụng được thực hiện.

Thiết kế kiến trúc

Sơ đồ thành phần, gói và triển khai giúp xác định cấu trúc của ứng dụng và cơ sở hạ tầng của nó.

Thiết kế chi tiết

Sơ đồ lớp, sơ đồ trình tự, sơ đồ máy trạng thái và sơ đồ cấu trúc tổng hợp có thể mô tả các trách nhiệm thực hiện và tương tác đối tượng.

Phát triển

Các nhà phát triển có thể sử dụng các mô hình làm tài liệu tham khảo trong khi thực hiện các lớp, dịch vụ, API và cấu trúc cơ sở dữ liệu.

Kiểm thử

Người kiểm thử có thể suy ra các kịch bản từ các trường hợp sử dụng, sơ đồ hoạt động và sơ đồ trình tự. Sơ đồ máy trạng thái có thể giúp xác định các chuyển đổi trạng thái hợp lệ và không hợp lệ.

Bảo trì

Biểu đồ UML cung cấp tài liệu cho các hệ thống hiện có và giúp các nhóm đánh giá tác động của các thay đổi được đề xuất.

Tạo biểu đồ UML với Visual Paradigm

Visual Paradigm là nền tảng mô hình hóa trực quan và thiết kế phần mềm hỗ trợ việc tạo biểu đồ UML cùng với các hoạt động mô hình hóa và phát triển khác. Các khả năng UML của nó bao gồm các biểu đồ như: lớp, chuỗi, trường hợp sử dụng, hoạt động, thành phần, triển khai, máy trạng thái, gói, đối tượng và cấu trúc tổng hợp.

Bắt đầu dự án UML

Quy trình làm việc thực tế trong Visual Paradigm là:

Tạo một dự án mới.
Tổ chức mô hình thành các gói như “Yêu cầu, Mô hình miền, Dịch vụ“, và “Triển khai.
Tạo biểu đồ trường hợp sử dụng để nắm bắt chức năng của hệ thống.
Thêm biểu đồ hoạt động hoặc biểu đồ chuỗi cho các quy trình làm việc quan trọng.
Tạo biểu đồ lớp cho mô hình miền.
Thêm biểu đồ thành phần và biểu đồ triển khai cho kiến trúc.
Xem xét các biểu đồ cùng với các bên liên quan.
Cập nhật mô hình khi hệ thống phát triển.
Xuất các biểu đồ hoặc tạo tài liệu khi cần thiết.

Tạo biểu đồ lớp

Để tạo biểu đồ lớp:

Tạo một biểu đồ lớp mới.
Thêm các lớp miền chính.
Thêm các thuộc tính và các phép toán.
Kết nối các lớp bằng các quan hệ phù hợp.
Thêm các số lượng.
Chỉ ra sự thừa kế và các giao diện khi cần thiết.
Sắp xếp biểu đồ sao cho các lớp liên quan dễ theo dõi.
Kiểm tra tính đúng đắn của mô hình so với các yêu cầu.

Ví dụ, một biểu đồ lớp cho cửa hàng trực tuyến có thể chứa Khách hàng, Đơn hàng, Sản phẩm, Thanh toán, và Vận chuyển.

Tạo biểu đồ trường hợp sử dụng

Biểu đồ trường hợp sử dụng có thể được tạo bằng cách:

Xác định các tác nhân bên ngoài.
Liệt kê các chức năng chính của hệ thống.
Thêm ranh giới hệ thống.
Đặt các trường hợp sử dụng bên trong ranh giới.
Kết nối các tác nhân với các trường hợp sử dụng mà họ tham gia.
Thêm các quan hệ bao gồm hoặc mở rộng chỉ khi chúng làm rõ việc tái sử dụng hoặc hành vi tùy chọn.

Tạo biểu đồ trình tự

Khi tạo biểu đồ trình tự:

Xác định kịch bản đang được mô hình hóa.
Thêm tác nhân hoặc thành phần khởi tạo.
Thêm các đối tượng hoặc dịch vụ tham gia.
Sắp xếp chúng từ trái sang phải.
Thêm các thông điệp theo thứ tự thời gian.
Mô hình hóa các phương án thay thế, vòng lặp và các điều kiện lỗi.
Đảm bảo rằng mỗi thông điệp đều tương ứng với một trách nhiệm thực tế.

Hợp tác và tài liệu hóa

Visual Paradigm cung cấp các khả năng mô hình hóa trực quan, tính năng hợp tác nhóm, hỗ trợ tài liệu hóa và các tích hợp nhằm kết nối việc mô hình hóa với các hoạt động phát triển phần mềm rộng lớn hơn. Nền tảng của nó cũng hỗ trợ việc xem xét và bình luận biểu đồ theo nhóm.

Một số phiên bản và quy trình làm việc cũng có thể cung cấp các tính năng như kỹ thuật mã nguồn, mô hình hóa cơ sở dữ liệu, tổ chức mô hình, xuất biểu đồ và tạo tài liệu. Các khả năng này nên được lựa chọn dựa trên nhu cầu của dự án thay vì được thêm tự động vào mọi mô hình.

Các thực hành tốt nhất cho việc mô hình hóa UML hiệu quả

Mô hình hóa với mục đích rõ ràng

Mọi biểu đồ đều phải trả lời một câu hỏi rõ ràng. Ví dụ:

Khách hàng đặt hàng như thế nào?
Dịch vụ nào phụ thuộc vào dịch vụ thanh toán?
Đơn hàng có thể chuyển sang những trạng thái nào?
Những lớp nào thuộc về miền đơn hàng?

Giữ cho các biểu đồ tập trung

Tránh đặt toàn bộ hệ thống trên một biểu đồ. Hãy chia các mô hình lớn thành các chế độ xem nhỏ hơn cho yêu cầu, cấu trúc miền, hành vi, kiến trúc và triển khai.

Sử dụng tên nhất quán

Sử dụng cùng một tên xuyên suốt các biểu đồ. Nếu một biểu đồ gọi một thành phần là “OrderService"“, thì biểu đồ khác không nên gọi nó là “OrderManager"” trừ khi chúng thực sự là các phần tử khác nhau.

Chọn mức độ chi tiết phù hợp

Sơ đồ dành cho các bên liên quan thường nên chứa ít chi tiết kỹ thuật hơn so với sơ đồ triển khai. Không thêm các chữ ký phương thức, trường cơ sở dữ liệu hoặc chi tiết cụ thể cho framework, trừ khi chúng liên quan đến đối tượng khán giả.

Tránh các mối quan hệ không cần thiết

Việc thêm mọi phụ thuộc có thể làm cho sơ đồ khó đọc. Hãy bao gồm các mối quan hệ truyền tải thông tin thiết kế có ý nghĩa.

Hiển thị số lượng (multiplicity) ở những nơi quan trọng

Số lượng giúp làm rõ các quy tắc kinh doanh và mối quan hệ dữ liệu. Ví dụ, việc chỉ ra rằng một đơn hàng chứa một hoặc nhiều mặt hàng đơn hàng sẽ cung cấp nhiều thông tin hơn là chỉ đơn giản kết nối hai lớp lại với nhau.

Kiểm tra sơ đồ đối chiếu với các yêu cầu

Một mô hình chỉ hữu ích khi nó đại diện chính xác cho hệ thống. Hãy so sánh các sơ đồ với các yêu cầu, kịch bản kiểm thử, mã nguồn và phản hồi từ các bên liên quan.

Sử dụng sơ đồ như tài liệu sống động

Cập nhật các sơ đồ UML khi các quyết định thiết kế quan trọng thay đổi. Các sơ đồ lỗi thời có thể gây nhầm lẫn hơn là không có sơ đồ nào cả.

Kết hợp các sơ đồ bổ trợ cho nhau

Không có một sơ đồ UML đơn lẻ nào giải thích mọi khía cạnh của một hệ thống. Sơ đồ lớp có thể hiển thị cấu trúc, trong khi sơ đồ trình tự giải thích cách cấu trúc đó hoạt động trong một kịch bản cụ thể.

Những lỗi phổ biến cần tránh

Xem UML như mã nguồn
Tạo sơ đồ mà không có mục đích cụ thể
Trộn lẫn chi tiết khái niệm và chi tiết triển khai mà không có giải thích
Sử dụng kế thừa ở những nơi mà tổ hợp sẽ phù hợp hơn
Bỏ sót số lượng (multiplicity) trong các mối quan hệ quan trọng
Thêm quá nhiều yếu tố vào một sơ đồ
Sử dụng các mối quan hệ include và extend không chính xác
Không mô hình hóa các luồng lỗi và các luồng thay thế
Cho phép các biểu đồ khác nhau sử dụng các tên không thống nhất
Giả định rằng một biểu đồ là chính xác chỉ vì nó trông có tổ chức về mặt trực quan

UML 2.x và số lượng biểu đồ

Các phiên bản UML sớm thường mô tả ít loại biểu đồ hơn.UML 2.x đã mở rộng ngôn ngữ và giới thiệu hoặc chính thức hóa các biểu đồ bổ sung, bao gồm:

Biểu đồ cấu trúc tổng hợp
Biểu đồ truyền thông
Biểu đồ tổng quan tương tác
Biểu đồ thời gian

Nó cũng đổi tên biểu đồ sơ đồ trạng thái thành biểu đồ máy trạng thái. Một phân loại phổ biến của UML 2.x bao gồm 14 biểu đồ: bảy biểu đồ cấu trúc và bảy biểu đồ hành vi. Nhóm hành vi bao gồm các biểu đồ: sử dụng, hoạt động, máy trạng thái, chuỗi, truyền thông, tổng quan tương tác và thời gian. Nhóm cấu trúc bao gồm các biểu đồ: lớp, đối tượng, thành phần, cấu trúc tổng hợp, triển khai, gói và hồ sơ.

Do đó, các danh sách mô tả UML 2.x chỉ có 13 biểu đồ là chưa đầy đủ theo phân loại 14 biểu đồ phổ biến.

Kết luận

UML cung cấp một ngôn ngữ trực quan thực tiễn để hiểu, thiết kế và tài liệu hóa các hệ thống phần mềm. Nó giúp các nhóm truyền đạt yêu cầu, khám phá kiến trúc, mô hình hóa mối quan hệ đối tượng, mô tả quy trình làm việc và giải thích hành vi thời gian chạy.

Các biểu đồ được sử dụng thường xuyên nhất thường là:

Biểu đồ trường hợp sử dụng cho các yêu cầu chức năng
Biểu đồ lớp cho cấu trúc tĩnh
Biểu đồ hoạt động cho quy trình làm việc
Biểu đồ chuỗi cho các tương tác
Biểu đồ thành phần cho kiến trúc
Sơ đồ triển khai cho cơ sở hạ tầng
Sơ đồ máy trạng thái cho hành vi vòng đời

Visual Paradigm có thể hỗ trợ quy trình mô hình hóa này bằng cách cung cấp các công cụ để tạo các sơ đồ UML, tổ chức các mô hình, cộng tác với các thành viên trong nhóm và tạo ra tài liệu kỹ thuật. Cách tiếp cận hiệu quả nhất không phải là sử dụng mọi sơ đồ UML một cách tùy tiện, mà là chọn các sơ đồ làm rõ các câu hỏi thiết kế quan trọng.

Khi được sử dụng nhất quán và duy trì sự phù hợp với hệ thống thực tế, UML trở nên nhiều hơn một bộ sưu tập các ký hiệu: nó trở thành một ngôn ngữ thiết kế chung kết nối các yêu cầu kinh doanh, kiến trúc phần mềm, triển khai, kiểm thử và bảo trì dài hạn.

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