UML Hiệu quả Tối thiểu: Hướng dẫn Thực hành Mô hình hóa Hệ thống Phần mềm

UML hữu ích nhất khi nó cải thiện giao tiếp và ra quyết định—không phải khi nó trở thành một bài tập tài liệu hóa. Một nhóm hiếm khi cần mọi loại biểu đồ UML. Trong hầu hết các dự án, bảy loại biểu đồ cung cấp nền tảng vững chắc:

1. Biểu đồ Use Case

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

3. Biểu đồ Chuỗi

4. Biểu đồ Lớp

5. Biểu đồ Thành phần

6. Biểu đồ Triển khai

7. Biểu đồ Máy trạng thái

Kết hợp lại, các biểu đồ này mô tả hệ thống từ các góc độ bổ sung:

• Mục tiêu:Người dùng và các hệ thống bên ngoài cần gì

• Hành vi:Công việc lưu chuyển qua hệ thống như thế nào

• Tương tác:Các đối tượng và dịch vụ hợp tác với nhau như thế nào

• Cấu trúc:Những thực thể và mối quan hệ nào tồn tại

• Kiến trúc:Các phần mềm chính được tổ chức như thế nào

• Vận hành:Hệ thống chạy ở đâu

• Vòng đời:Các đối tượng quan trọng thay đổi theo thời gian như thế nào

Mục tiêu không phải là tạo ra một biểu đồ cho mọi mối quan tâm có thể. Mục tiêu là tạo ra bộ mô hình nhỏ nhất, mạch lạc nhất để trả lời những câu hỏi mà các bên liên quan thực sự có.

1. Ý nghĩa của ‘UML Hiệu quả Tối thiểu’

UML Hiệu quả Tối thiểu là một chiến lược mô hình hóa dựa trên bốn nguyên tắc:

• Mô hình hóa cho một quyết định:Tạo biểu đồ vì nó làm rõ một yêu cầu, lựa chọn thiết kế, rủi ro hoặc chi tiết triển khai.

• Sử dụng ký hiệu đơn giản nhất nhưng đủ dùng:Tránh các ký hiệu, trang trí và chi tiết không cần thiết.

• Duy trì khả năng truy vết:Liên kết các yêu cầu với hành vi, cấu trúc, mã nguồn, bài kiểm tra và triển khai khi khả thi.

• Giữ cho các sơ đồ dễ hiểu:Một sơ đồ chứa đựng mọi thứ thường không truyền tải được điều gì cả.

Một mô hình hữu ích nên giúp trả lời các câu hỏi như:

• Ai tương tác với hệ thống?

• Hệ thống phải cung cấp những khả năng nào?

• Những bước nào tạo nên một quy trình kinh doanh?

• Đối tượng hoặc dịch vụ nào chịu trách nhiệm cho mỗi hành động?

• Những dữ liệu và khái niệm miền nào phải được biểu diễn?

• Các phân hệ được chia như thế nào?

• Các ứng dụng, cơ sở dữ liệu và dịch vụ bên ngoài được triển khai ở đâu?

• Một thực thể quan trọng chuyển đổi qua vòng đời của nó như thế nào?

Nếu một sơ đồ không giúp trả lời một trong những câu hỏi này, nó có thể không cần thiết.

2. Cốt lõi bảy sơ đồ

Các biểu đồ này không độc lập. Chúng tạo thành một chuỗi:

Sơ đồ máy trạng thái cắt ngang qua chuỗi này bằng cách mô tả vòng đời của các đối tượng có các trạng thái có ý nghĩa.

Ví dụ, một đơn hàng trực tuyến có thể được biểu diễn như sau:

• Trường hợp sử dụng:Đặt hàng

• Hoạt động:Xác thực giỏ hàng, ủy quyền thanh toán, đặt chỗ hàng tồn kho, xác nhận đơn hàng

• Chuỗi:Giao diện khách hàng gọi dịch vụ đơn hàng, dịch vụ thanh toán và dịch vụ tồn kho

• Lớp: Đơn hàng, Dòng đơn hàng, Thanh toán, và Sản phẩm

• Thành phần:Ứng dụng web, dịch vụ đơn hàng, bộ chuyển đổi thanh toán, dịch vụ tồn kho

• Triển khai:Trình duyệt, cụm ứng dụng, cơ sở dữ liệu, nhà cung cấp thanh toán

• Máy trạng thái:Nháp → Chờ thanh toán → Đã thanh toán → Đã giao hàng → Đã giao

3. Sơ đồ trường hợp sử dụng: Xác định mục tiêu hệ thống

Sơ đồ trường hợp sử dụng trình bày hệ thống từ bên ngoài. Nó xác định các tác nhân tương tác với hệ thống và các mục tiêu mà họ theo đuổi.

3.1 Sơ đồ trường hợp sử dụng chứa những gì

Các yếu tố chính là:

• Biên giới hệ thống:Xác định những gì nằm bên trong hệ thống đang được mô hình hóa

• Các vai trò:Con người, tổ chức, thiết bị hoặc hệ thống bên ngoài

• Các trường hợp sử dụng:Mục tiêu hoặc dịch vụ mà hệ thống cung cấp

• Các mối liên kết:Kết nối giữa các vai trò và các trường hợp sử dụng

• Mối quan hệ bao gồm:Hành vi có thể tái sử dụng được yêu cầu bởi một trường hợp sử dụng khác

• Mối quan hệ mở rộng:Hành vi tùy chọn hoặc có điều kiện

Ví dụ:

@startuml
left to right direction

actor Customer
actor "Payment Provider" as PaymentProvider
actor "Warehouse System" as Warehouse

rectangle "Online Store" {
  usecase "Browse Products" as UC1
  usecase "Place Order" as UC2
  usecase "Authorize Payment" as UC3
  usecase "Fulfill Order" as UC4
}

Customer --> UC1
Customer --> UC2
UC2 ..> UC3 : <<include>>
PaymentProvider --> UC3
Warehouse --> UC4
@enduml

3.2 Xác định đúng các vai trò

Một vai trò không nhất thiết là một vai trò con người. Đó là bất kỳ thứ gì bên ngoài tương tác với hệ thống.

Các vai trò có thể bao gồm:

• Khách hàng

• Nhân viên hỗ trợ

• Quản trị viên

• Cổng thanh toán

• Nhà cung cấp danh tính

• Hệ thống quản lý kho

• Công việc được lên lịch

• Ứng dụng di động

• Thiết bị IoT

Tránh đặt tên cho các vai dựa trên các chi tiết triển khai nội bộ. “Bộ điều khiển REST” thường không phải là một vai. “Ứng dụng đối tác” có thể là một vai.

3.3 Đặt tên cho các kịch bản sử dụng theo mục tiêu

Tên kịch bản sử dụng tốt mô tả kết quả:

• Gửi báo cáo chi phí

• Duyệt yêu cầu mua hàng

• Đăng ký bệnh nhân mới

• Tạo hóa đơn

• Đặt lại mật khẩu

Tên yếu mô tả cơ chế triển khai:

• Gọi API

• Chạy truy vấn SQL

• Mở biểu mẫu

• Gọi bộ điều khiển

Một kịch bản sử dụng cần trả lời:

Kết quả có ý nghĩa nào mà một vai muốn đạt được với hệ thống?

3.4 Khi nào sử dụng include và extend

Sử dụng<<include>>khi một hành vi luôn được yêu cầu như một phần của hành vi khác.

Ví dụ:

• “Đặt hàng” bao gồm “Tính tổng”

• “Đăng ký tài khoản” bao gồm “Xác thực email”

Sử dụng<<extend>>khi hành vi là tùy chọn hoặc có điều kiện.

Ví dụ:

• “Đặt hàng” có thể được mở rộng bởi “Áp dụng giảm giá khuyến mãi”

• “Đăng nhập” có thể được mở rộng bởi “Hoàn tất xác thực đa yếu tố”

Không sử dụng các mối quan hệ này chỉ để làm cho sơ đồ trông phức tạp hơn. Thường thì một kịch bản văn bản ngắn hoặc sơ đồ hoạt động rõ ràng hơn.

3.5 Những gì sơ đồ kịch bản sử dụng không hiển thị

Biểu đồ trường hợp sử dụng không nhằm mục đích mô tả:

• Bố cục chi tiết của giao diện người dùng

• Các lớp triển khai chính xác

• Các bảng cơ sở dữ liệu

• Thứ tự của các thông điệp

• Logic thuật toán

• Cấu trúc liên kết hạ tầng

Chúng xác định phạm vi và mục tiêu. Các biểu đồ khác cung cấp chi tiết.

4. Biểu đồ hoạt động: Mô hình hóa quy trình làm việc và quy trình nghiệp vụ

Biểu đồ hoạt động cho thấy công việc được thực hiện như thế nào. Chúng đặc biệt hiệu quả đối với các quy trình nghiệp vụ, quy trình làm việc, logic phân nhánh, công việc song song và xử lý ngoại lệ.

4.1 Các thành phần cốt lõi

Biểu đồ hoạt động thường sử dụng:

• Các nút khởi tạo

• Các hành động

• Các nút quyết định

• Các nút hợp nhất

• Các nhánh rẽ và hợp

• Các làn bơi

• Các nút kết thúc

• Các điều kiện bảo vệ như [đã phê duyệt] hoặc [bị từ chối]

Ví dụ:

@startuml
|Khách hàng|
start
:Đặt hàng;

|Dịch vụ Đơn hàng|
:Rà soát đơn hàng;

if (Đơn hàng hợp lệ?) then (có)
  :Tính tổng;

  fork
    |Dịch vụ Thanh toán|
    :Xác thực thanh toán;
  fork again
    |Dịch vụ Kho|
    :Dự trữ hàng tồn kho;
  end fork

  |Dịch vụ Đơn hàng|
  :Xác nhận đơn hàng;
  stop
else (không)
  :Trả về lỗi rà soát;
  stop
endif
@enduml

4.2 Sử dụng làn bơi để thể hiện trách nhiệm

Các làn bơi làm rõ vai trò, hệ thống hoặc thành phần nào thực hiện mỗi hành động.

Các làn hữu ích có thể đại diện cho:

• Khách hàng

• Nhân viên chăm sóc khách hàng

• Dịch vụ đơn hàng

• Nhà cung cấp thanh toán

• Kho hàng

• Bộ lập lịch tự động

Các làn bơi đặc biệt có giá trị khi một quy trình vượt qua ranh giới tổ chức hoặc hệ thống.

4.3 Mô hình hóa các quyết định một cách rõ ràng

Một quyết định nên có các điều kiện bảo vệ có ý nghĩa:

[Thanh toán được phê duyệt]
[Thanh toán bị từ chối]

Tránh các nhãn mơ hồ như:

[có]
[không]

trừ khi câu hỏi ra quyết định là hiển nhiên ngay lập tức.

4.4 Thể hiện tính song song khi nó quan trọng

Các nhánh rẽ và hợp nhất hữu ích khi các hoạt động xảy ra đồng thời. Ví dụ, sau khi đơn hàng được xác thực:

• Thanh toán có thể được ủy quyền

• Tồn kho có thể được đặt trước

• Một cuộc kiểm tra gian lận có thể được thực hiện

Tuy nhiên, chỉ mô hình hóa tính song song khi nó ảnh hưởng đến thời gian, tính nhất quán, xử lý lỗi hoặc thiết kế hệ thống. Không sử dụng các nhánh song song chỉ để làm cho sơ đồ trở nên phức tạp hơn.

4.5 Sơ đồ hoạt động và yêu cầu

Một sơ đồ hoạt động có thể làm lộ ra các yêu cầu bị thiếu. Ví dụ, trong khi mô hình hóa quy trình phê duyệt, nhóm có thể phát hiện ra những câu hỏi chưa được trả lời:

• Điều gì sẽ xảy ra nếu người phê duyệt không có sẵn?

• Một yêu cầu có thể bị từ chối và gửi lại không?

• Thời gian chuyển cấp là bao lâu?

• Hai người có thể phê duyệt đồng thời không?

• Điều gì sẽ xảy ra nếu hệ thống phía sau không có sẵn?

Điều này làm cho biểu đồ hoạt động trở nên hữu ích trước khi bắt đầu triển khai.

5. Biểu đồ trình tự: Giải thích sự hợp tác theo thời gian

Biểu đồ trình tự cho thấy cách các thành phần trao đổi thông điệp trong một tương tự có thứ tự thời gian. Chúng rất lý tưởng để mô tả chi tiết các kịch bản quan trọng.

5.1 Các thành phần chính

Một biểu đồ trình tự thường bao gồm:

• Các vai trò

• Đối tượng hoặc dịch vụ

• Đường sự sống

• Thông điệp

• Thông điệp trả về

• Thanh kích hoạt

• Điều kiện

• Vòng lặp

• Các đường dẫn thay thế

• Thông điệp không đồng bộ

Ví dụ:

@startuml
actor Customer
boundary "Web App" as Web
control "Order Service" as Order
control "Payment Service" as Payment
database "Order DB" as DB

Customer -> Web : Submit order
Web -> Order : createOrder(cart)

Order -> DB : save(order)
DB --> Order : orderId

Order -> Payment : authorize(amount)

alt Payment approved
  Payment --> Order : approved
  Order -> DB : updateStatus(PAID)
  Order --> Web : confirmation
  Web --> Customer : Display confirmation
else Payment declined
  Payment --> Order : declined
  Order -> DB : updateStatus(PAYMENT_FAILED)
  Order --> Web : payment error
  Web --> Customer : Display error
end
@enduml

5.2 Chọn kịch bản một cách chiến lược

Đừng tạo biểu đồ trình tự cho mọi trường hợp sử dụng. Hãy bắt đầu với các kịch bản sau:

• Quan trọng đối với kinh doanh

• Rủi ro về kỹ thuật

• Phụ thuộc nhiều vào tích hợp

• Nhạy cảm về bảo mật

• Giao dịch

• Khó hiểu

• Có khả năng làm lộ các vấn đề kiến trúc

Các ví dụ điển hình bao gồm:

• Xác thực người dùng

• Xử lý thanh toán

• Tải lên tệp

• Gửi đơn hàng

• Đặt lại mật khẩu

• Công bố sự kiện

• Khôi phục sau sự cố

• Thực thi tác vụ nền

5.3 Phân biệt tương tác đồng bộ và bất đồng bộ

Một lời gọi đồng bộ có nghĩa là người gửi chờ phản hồi. Một tin nhắn bất đồng bộ cho phép người gửi tiếp tục.

Sự phân biệt này ảnh hưởng đến:

• Trải nghiệm người dùng

• Giới hạn giao dịch

• Xử lý lỗi

• Khả năng mở rộng

• Hành vi thử lại

• Khả năng quan sát

Sử dụng ký hiệu khác nhau một cách thống nhất và giải thích các hành vi bất đồng bộ quan trọng trong một ghi chú hoặc văn bản đi kèm.

5.4 Mô hình hóa các đường dẫn lỗi

Một biểu đồ trình tự chỉ hiển thị đường dẫn thành công có thể che giấu các rủi ro thiết kế lớn. Sử dụng alt, opt, và loop để hiển thị:

• Lỗi xác thực

• Lỗi xác thực

• Hết thời gian chờ

• Thử lại

• Lỗi một phần

• Y cầu trùng lặp

• Dịch vụ không khả dụng

• Bù đắp hoặc hoàn tác

Ví dụ:

@startuml
Client -> API : Gửi yêu cầu

API -> Service : Xử lý yêu cầu

alt Dịch vụ phản hồi
  Service --> API : Kết quả
  API --> Client : Thành công
else Hết thời gian chờ
  API -> Service : Thử lại yêu cầu
  alt Thử lại thành công
    Service --> API : Kết quả
    API --> Client : Thành công
  else Thử lại thất bại
    API --> Client : Lỗi tạm thời
  end
end
@enduml

5.5 Tránh các sơ đồ trình tự quá chi tiết

Sơ đồ trình tự trở nên khó bảo trì khi nó bao gồm mọi lời gọi phương thức nội bộ. Hãy tập trung vào các trách nhiệm và ranh giới có ý nghĩa:

• Giao diện người dùng

• Dịch vụ ứng dụng

• Đối tượng miền

• Kho lưu trữ

• Dịch vụ bên ngoài

• Trình trung gian tin nhắn

• Cơ sở dữ liệu

Các sơ đồ triển khai chi tiết có thể hữu ích trong quá trình gỡ lỗi, nhưng chúng không nên trở thành tài liệu kiến trúc chính.

6. Sơ đồ lớp: Mô tả cấu trúc và khái niệm miền

Sơ đồ lớp hiển thị cấu trúc tĩnh. Chúng có thể mô tả một trong các loại sau:

• Mô hình miền khái niệm

• Mô hình đối tượng ở mức thiết kế

• Cấu trúc lớp hướng triển khai

Đây là các mức trừu tượng khác nhau và không nên trộn lẫn một cách tùy tiện.

6.1 Sơ đồ lớp khái niệm so với sơ đồ lớp triển khai

Một mô hình khái niệm có thể bao gồm:

• Khách hàng

• Đơn hàng

• Sản phẩm

• Thanh toán

Một mô hình triển khai có thể bao gồm:

• OrderController

• OrderApplicationService

• OrderRepository

• PaymentGatewayAdapter

Cả hai đều hợp lệ, nhưng chúng trả lời những câu hỏi khác nhau.

6.2 Các mối quan hệ cốt lõi

Các mối quan hệ phổ biến bao gồm:

• Liên kết

• Tụ hợp

• Tổng hợp

• Tổng quát hóa

• Phụ thuộc

• Hiện thực hóa

Hãy sử dụng các mối quan hệ một cách thận trọng. Trong nhiều trường hợp, một liên kết đơn giản rõ ràng hơn là sự phân biệt phức tạp giữa tụ hợp và tổng hợp.

Ví dụ:

@startuml
class Customer {
  +id: CustomerId
  +name: String
  +email: EmailAddress
}

class Order {
  +id: OrderId
  +status: OrderStatus
  +total(): Money
  +submit()
}

class OrderLine {
  +quantity: int
  +unitPrice: Money
  +lineTotal(): Money
}

class Product {
  +sku: String
  +name: String
}

Customer "1" -- "0..*" Order : places
Order "1" *-- "1..*" OrderLine : contains
OrderLine "*" --> "1" Product : refers to
@enduml

6.3 Tính đa trị là quan trọng

Tính đa trị biểu thị các ràng buộc:

• 1 — chính xác một

• 0..1 — tùy chọn

• * — nhiều

• 1..* — một hoặc nhiều

Ví dụ:

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

có nghĩa là mỗi đơn hàng thuộc về một khách hàng, trong khi một khách hàng có thể có không hoặc nhiều đơn hàng.

6.4 Mô hình hóa các trách nhiệm, không chỉ các trường dữ liệu

Biểu đồ lớp nên giúp giải thích nơi hành vi thuộc về. Một đối tượng miền có các thao tác có ý nghĩa thường cung cấp nhiều thông tin hơn một tập hợp các lớp chỉ chứa các phương thức getter và setter.

Ví dụ:

Order.submit()
Order.cancel()
Order.calculateTotal()
Payment.authorize()

Các thao tác cụ thể phụ thuộc vào phương pháp thiết kế, nhưng nguyên tắc là nhất quán:

Đặt các trách nhiệm kinh doanh quan trọng gần với các khái niệm sở hữu chúng.

6.5 Tránh biến biểu đồ lớp thành lược đồ cơ sở dữ liệu

Biểu đồ lớp không tự động là một lược đồ quan hệ. Đừng thêm mọi cột cơ sở dữ liệu trừ khi mục đích cụ thể là thiết kế lưu trữ.

Một sự phân biệt hữu ích là:

• Mô hình miền: Các khái niệm và quy tắc kinh doanh

• Mô hình thiết kế: Các lớp phần mềm và trách nhiệm

• Mô hình dữ liệu: Các bảng, khóa, chỉ mục và ràng buộc

Chúng có thể liên quan đến nhau, nhưng không nên bị nhầm lẫn.

7. Biểu đồ thành phần: Thể hiện các ranh giới kiến trúc

Sơ đồ thành phần mô tả các bộ phận chính có thể thay thế hoặc triển khai của hệ thống và các giao diện thông qua đó chúng tương tác.

Chúng hữu ích để trả lời các câu hỏi sau:

• Các hệ thống con chính là gì?

• Thành phần nào chịu trách nhiệm?

• Mỗi thành phần cung cấp gì?

• Mỗi thành phần yêu cầu gì?

• Các ranh giới tích hợp nằm ở đâu?

• Những phụ thuộc nào là ổn định hoặc rủi ro?

Ví dụ:

@startuml
component "Web Application" as Web
component "Order Service" as Order
component "Payment Adapter" as Payment
component "Inventory Service" as Inventory
database "Order Database" as DB
cloud "External Payment Provider" as Provider

Web --> Order : REST API
Order --> Payment : Payment interface
Order --> Inventory : Inventory API
Order --> DB : Persistence
Payment --> Provider : Provider API
@enduml

7.1 Sơ đồ thành phần không phải là sơ đồ gói

Sơ đồ gói nhóm các phần tử mô hình, thường để tổ chức. Sơ đồ thành phần mô tả các đơn vị kiến trúc cung cấp và tiêu thụ chức năng.

Một thành phần có thể là:

• Một dịch vụ có thể triển khai

• Một ứng dụng web

• Một ứng dụng di động

• Một thư viện

• Một bộ chuyển tiếp tin nhắn

• Một nền tảng bên ngoài

• Một cơ sở dữ liệu

• Một tích hợp bên thứ ba

Mức độ phù hợp phụ thuộc vào kiến trúc.

7.2 Hiển thị giao diện ở những nơi làm rõ hợp đồng

Giao diện làm cho các phụ thuộc rõ ràng hơn:

@startuml
interface PaymentGateway

component "Order Service" as Order
component "Payment Adapter" as Adapter

Order ..> PaymentGateway
Adapter - PaymentGateway
@enduml

Điều này cho thấy dịch vụ đơn hàng phụ thuộc vào một sự trừu tượng hóa thay vì một nhà cung cấp cụ thể.

7.3 Sử dụng sơ đồ thành phần để hỗ trợ các quyết định kiến trúc

Một sơ đồ thành phần trở nên có giá trị hơn khi được kết hợp với các ghi chú thiết kế ngắn gọn:

• Tại sao ranh giới này lại tồn tại?

• Ai sở hữu dữ liệu?

• Tương tác là đồng bộ hay bất đồng bộ?

• Điều gì xảy ra khi sự phụ thuộc bị lỗi?

• Thành phần có thể được triển khai độc lập không?

• Nó đại diện cho ranh giới bảo mật nào?

• Những đảm bảo về tính nhất quán nào tồn tại?

Sơ đồ không cần phải chứa mọi câu trả lời, nhưng nó nên hướng sự chú ý đến những câu trả lời quan trọng.

8. Sơ đồ triển khai: Kết nối phần mềm với cơ sở hạ tầng

Sơ đồ triển khai hiển thị môi trường vật lý hoặc ảo nơi các sản phẩm phần mềm được thực thi.

Chúng giúp trả lời:

• Mỗi ứng dụng chạy ở đâu?

• Các nút nào giao tiếp với nhau?

• Cơ sở dữ liệu được đặt ở đâu?

• Dịch vụ nào có thể truy cập từ bên ngoài?

• Những ranh giới mạng nào tồn tại?

• Hệ thống được phân phối như thế nào?

• Những lựa chọn cơ sở hạ tầng nào ảnh hưởng đến độ tin cậy hoặc hiệu suất?

Ví dụ:

@startuml
node "Thiết bị Người dùng" as Device {
  artifact "Trình duyệt" as Browser
}

node "Vùng Đám mây" as Cloud {
  node "Lớp Web" as WebTier {
    artifact "Ứng dụng Web" as WebApp
  }

  node "Lớp Ứng dụng" as AppTier {
    artifact "Dịch vụ Đơn hàng" as OrderSvc
    artifact "Bộ chuyển đổi Thanh toán" as PaymentSvc
  }

  database "Cơ sở dữ liệu Đơn hàng" as DB
}

cloud "Nhà cung cấp Thanh toán" as Provider

Browser --> WebApp : HTTPS
WebApp --> OrderSvc : HTTPS
OrderSvc --> DB : TLS
OrderSvc --> PaymentSvc
PaymentSvc --> Provider : HTTPS
@enduml

8.1 Phân biệt các nút, tài sản và môi trường

• Một nút là môi trường thực thi, chẳng hạn như máy chủ, container, thiết bị, máy ảo hoặc nền tảng được quản lý.

• Một tài sản là đơn vị phần mềm có thể triển khai, chẳng hạn như tệp nhị phân, hình ảnh container, gói hoặc ứng dụng.

• Một môi trường có thể đại diện cho phát triển, kiểm thử, giai đoạn thử nghiệm hoặc sản xuất.

8.2 Bao gồm các chi tiết quan trọng về vận hành

Tùy theo mục đích, sơ đồ triển khai có thể hiển thị:

• Bộ cân bằng tải

• Tường lửa

• Vùng mạng

• Cụm container

• Vùng sẵn sàng

• Cơ sở dữ liệu và bản sao

• Bộ nhớ đệm

• Bộ trung gian tin nhắn

• Lưu trữ đối tượng

• Dịch vụ bên ngoài

• Hệ thống giám sát và ghi nhật ký

Không thêm các chi tiết cơ sở hạ tầng không ảnh hưởng đến quyết định đang được ghi lại.

8.3 Sử dụng sơ đồ triển khai để phân tích rủi ro

Mô hình hóa triển khai có thể tiết lộ:

• Điểm lỗi đơn lẻ

• Cơ sở dữ liệu bị phơi bày

• Ranh giới mạng bị thiếu

• Lưu lượng giữa các vùng quá mức

• Sự phụ thuộc không có chiến lược dự phòng

• Sự tách biệt không đầy đủ giữa các môi trường

• Kết nối không được mã hóa

• Giả định mở rộng không thực tế

9. Sơ đồ máy trạng thái: Mô hình hóa vòng đời

Sơ đồ máy trạng thái mô tả cách một thực thể phản ứng với các sự kiện bằng cách chuyển đổi giữa các trạng thái.

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

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

• Đơn hàng

• Thanh toán

• Vận chuyển

• Phiếu hỗ trợ

• Tài khoản người dùng

• Yêu cầu quy trình làm việc

• Đăng ký

• Tài liệu

• Thiết bị

• Thực thi công việc

Ví dụ:

@startuml
[*] --> Dự thảo

Dự thảo --> Chờ thanh toán : gửi
Chờ thanh toán --> Đã thanh toán : thanh toán được phê duyệt
Chờ thanh toán --> Thanh toán thất bại : thanh toán bị từ chối
Thanh toán thất bại --> Chờ thanh toán : thử lại thanh toán
Đã thanh toán --> Đang xử lý : bắt đầu thực hiện
Đang xử lý --> Đã giao : gửi hàng
Đã giao --> Đã giao thành công : xác nhận giao hàng
Đã thanh toán --> Đã hủy : hủy
Đang xử lý --> Đã hủy : hủy nếu được phép
Đã giao thành công --> [*]
Đã hủy --> [*]
@enduml

9.1 Xác định trạng thái cẩn thận

Một trạng thái nên đại diện cho một điều kiện có ý nghĩa, không chỉ là một hành động.

Trạng thái tốt:

• Đang chờ phê duyệt

• Đã phê duyệt

• Bị từ chối

• Thanh toán thất bại

• Đã giao hàng

Trạng thái yếu:

• Nhấp vào nút

• Gọi dịch vụ

• Đang chạy phương thức

Hành động là sự kiện hoặc chuyển tiếp. Trạng thái là các điều kiện tồn tại.

9.2 Bao gồm các quy tắc chuyển tiếp

Một chuyển tiếp có thể bao gồm:

• Sự kiện

• Điều kiện bảo vệ

• Hành động

Ví dụ:

Đang chờ phê duyệt -- approve [quản lý được ủy quyền] / recordApproval --> Đã phê duyệt

Điều này làm cho các quy tắc kinh doanh trở nên rõ ràng và có thể kiểm thử.

9.3 Sử dụng máy trạng thái để suy ra các bài kiểm thử

Mỗi chuyển tiếp gợi ý các trường hợp kiểm thử:

• Chuyển tiếp hợp lệ

• Chuyển tiếp không hợp lệ

• Lỗi điều kiện bảo vệ

• Sự kiện lặp lại

• Hết thời gian chờ

• Thử lại

• Hủy bỏ

• Khôi phục

Đối với vòng đời đơn hàng, các bài kiểm tra có thể xác minh:

• Đơn hàng nháp có thể được gửi

• Đơn hàng đã giao không thể bị hủy

• Lỗi thanh toán cho phép thử lại

• Đơn hàng đã hủy không thể quay lại trạng thái đã thanh toán

10. Cách bảy sơ đồ phối hợp với nhau

Các sơ đồ nên tạo thành một mô hình thống nhất thay vì bảy hình minh họa rời rạc.

Hãy xem xét khả năng “Gửi báo cáo chi phí”.

Trường hợp sử dụng

• Nhân viên gửi báo cáo chi phí

• Quản lý phê duyệt báo cáo chi phí

• Nhân viên tài chính xử lý hoàn tiền

Hoạt động

• Nhập chi phí

• Đính kèm hóa đơn

• Xác thực dữ liệu

• Gửi báo cáo

• Chuyển đến quản lý

• Phê duyệt hoặc từ chối

• Gửi đến bộ phận tài chính

Trình tự

• Giao diện nhân viên gọi dịch vụ chi phí

• Dịch vụ chi phí xác thực báo cáo

• Dịch vụ hóa đơn lưu trữ các tệp đính kèm

• Dịch vụ quy trình công việc chỉ định quản lý

• Dịch vụ thông báo gửi cảnh báo

Lớp

• Nhân viên

• Báo cáo chi phí

• Mục chi phí

• Hóa đơn

• Phê duyệt

• Hoàn trả

Thành phần

• Ứng dụng web

• Dịch vụ chi phí

• Lưu trữ hóa đơn

• Dịch vụ quy trình làm việc

• Dịch vụ thông báo

• Tích hợp tài chính

Triển khai

• Trình duyệt

• Lớp web

• Cụm ứng dụng

• Lưu trữ đối tượng

• Cơ sở dữ liệu quan hệ

• Nền tảng tài chính

Máy trạng thái

Nháp → Đã gửi → Đang xem xét → Đã phê duyệt → Đã hoàn trả
                         ↓
                      Bị từ chối

Mỗi biểu đồ cung cấp một góc nhìn khác nhau mà không lặp lại tất cả các góc nhìn khác.

11. Lựa chọn các biểu đồ cần tạo

Một quy trình lựa chọn thực tế là đặt câu hỏi về loại bất định mà nhóm đang gặp phải.

Bạn không cần biểu đồ cho mọi tính năng.

Một quy tắc ra quyết định nhẹ

Tạo biểu đồ khi ít nhất một trong các điều sau đúng:

• Nhiều bên liên quan diễn giải yêu cầu khác nhau.

• Một quy trình có hành vi phân nhánh hoặc song song quan trọng.

• Một kịch bản vượt qua nhiều ranh giới hệ thống.

• Một đối tượng trong lĩnh vực có các quy tắc không tầm thường.

• Một quyết định kiến trúc cần được truyền đạt.

• Cấu trúc triển khai ảnh hưởng đến độ tin cậy, bảo mật hoặc hiệu suất.

• Các quy tắc vòng đời khó giải thích bằng văn xuôi.

• Biểu đồ sẽ được tái sử dụng cho việc triển khai, rà soát, kiểm thử hoặc vận hành.

Tránh tạo biểu đồ chỉ vì một mẫu yêu cầu điều đó.

12. Mức độ chi tiết

Một thực hành mô hình hóa mạnh mẽ sử dụng nhiều mức trừu tượng hóa.

Mức ngữ cảnh

Hiển thị hệ thống và các tác nhân hoặc hệ thống bên ngoài chính.

Có ích cho:

• Phạm vi

• Giao tiếp với các bên liên quan

• Ranh giới hệ thống

Mức container hoặc phân hệ

Hiển thị các ứng dụng, dịch vụ, cơ sở dữ liệu và các tích hợp chính.

Có ích cho:

• Kiến trúc

• Quyền sở hữu

• Lập kế hoạch triển khai

Mức thành phần

Hiển thị các bộ phận kiến trúc nội bộ và các giao diện.

Có ích cho:

• Thiết kế chi tiết

• Rà soát phụ thuộc

• Ranh giới nhóm

Mức mã nguồn

Hiển thị các lớp, phương thức và các phụ thuộc thực thi.

Có ích cho:

• Công việc của nhà phát triển

• Tái cấu trúc

• Gỡ lỗi

Không đặt tất cả các mức vào một biểu đồ. Biểu đồ ngữ cảnh không nên chứa mọi lớp, và biểu đồ lớp không nên cố gắng biểu diễn toàn bộ mạng sản xuất.

13. Visual Paradigm UML

Visual Paradigm rất phù hợp với các nhóm ưa thích mô hình hóa đồ họa và tài liệu tích hợp.

Nó có thể hữu ích cho:

• Vẽ biểu đồ UML tương tác

• Duy trì kho lưu trữ mô hình

• Liên kết biểu đồ với các yêu cầu

• Tạo các mối quan hệ truy vết

• Sản xuất tài liệu

• Hợp tác thông qua môi trường mô hình hóa dùng chung

• Tạo ra hoặc phân tích ngược các sản phẩm đã chọn

• Quản lý các mô hình lớn với các tính năng điều hướng và tổ chức

13.1 Điểm mạnh

Các công cụ UML đồ họa đặc biệt hữu ích khi:

• Các nhà phân tích và người không phải lập trình viên cần chỉnh sửa sơ đồ

• Các bên liên quan ưa thích thao tác trực quan

• Dự án yêu cầu tổ chức mô hình chính thức

• Khả năng truy vết là quan trọng

• Nhóm duy trì một kho lưu trữ trung tâm

• Tài liệu phải được tạo ra một cách nhất quán

13.2 Khuyến nghị sử dụng

Sử dụng Visual Paradigm cho các chế độ xem mô hình được hưởng lợi từ:

• Bố cục tương tác

• Ghi chú phong phú

• Điều hướng giữa các sơ đồ

• Quản lý kho lưu trữ chính thức

• Khả năng truy vết

• Hội thảo với các bên liên quan

Không để công cụ tự quyết định chiến lược mô hình hóa. Trước tiên, hãy quyết định:

• Quyết định nào mà sơ đồ hỗ trợ

• Ai sẽ đọc nó

• Mức độ chi tiết nào là phù hợp

• Nó sẽ được duy trì như thế nào

• Liệu mô hình có cần kết nối với yêu cầu hoặc mã nguồn hay không

13.3 Kỷ luật kho lưu trữ

Một kho lưu trữ mô hình dùng chung được hưởng lợi từ các thực hành tương tự như kiểm soát nguồn:

• Xây dựng quy ước đặt tên

• Phân công quyền sở hữu các khu vực chính của mô hình

• Xem xét các thay đổi quan trọng

• Tránh các sơ đồ trùng lặp không cần thiết

• Lưu trữ các chế độ xem lỗi thời

• Ghi lại mục đích của các sơ đồ quan trọng

• Đảm bảo các phần tử mô hình được đặt tên nhất quán

14. VPasCode và Mô hình hóa dựa trên văn bản

VPasCode hỗ trợ cách tiếp cận mô hình hóa định hướng văn bản trong hệ sinh thái Visual Paradigm. Phong cách này hữu ích cho các nhóm muốn sơ đồ hoạt động giống như các tài nguyên nguồn hơn.

Sơ đồ dựa trên văn bản có thể mang lại:

• Tương thích với hệ thống kiểm soát phiên bản

• Rà soát mã nguồn

• Phân nhánh và hợp nhất

• Tự động tạo

• Xây dựng có thể lặp lại

• Cập nhật hàng loạt dễ dàng hơn

• Gần gũi với mã nguồn và tài liệu

Một mô hình dựa trên văn bản có thể trông như sau:

actor Customer
usecase "Place Order" as PlaceOrder
Customer --> PlaceOrder

Cú pháp chính xác phụ thuộc vào công cụ và quy trình làm việc, nhưng lợi ích rộng lớn hơn là sơ đồ được biểu diễn dưới dạng văn bản có thể chỉnh sửa thay vì chỉ là tệp đồ họa.

14.1 Khi nào mô hình hóa dựa trên văn bản hoạt động hiệu quả

Sử dụng sơ đồ dựa trên văn bản khi:

• Các nhà phát triển duy trì các mô hình

• Sơ đồ thay đổi thường xuyên

• Nhóm sử dụng Git hoặc một hệ thống kiểm soát phiên bản khác

• Người rà soát muốn kiểm tra các thay đổi về văn bản

• Sơ đồ được tạo như một phần của tài liệu

• Nhiều nhánh cần phát triển độc lập

14.2 Các hạn chế tiềm ẩn

Mô hình hóa dựa trên văn bản có thể kém thuận tiện hơn khi:

• Các bên liên quan trong kinh doanh cần chỉnh sửa sơ đồ trực tiếp

• Bố cục phải được tối ưu hóa thủ công

• Mô hình chứa các chú thích trực quan phong phú

• Nhóm chưa quen với cú pháp sơ đồ

• Kho lưu trữ yêu cầu điều hướng trực quan phức tạp

Một cách tiếp cận lai thường hiệu quả: sử dụng sơ đồ dựa trên văn bản cho kiến trúc hướng mã và công cụ đồ họa cho phân tích hướng đến các bên liên quan.

15. PlantUML

PlantUML là một phương pháp vẽ sơ đồ dựa trên văn bản phổ biến, có thể tạo ra các sơ đồ UML và các sơ đồ kiến trúc liên quan từ văn bản thuần túy.

Ví dụ:

@startuml
actor User
participant "Web App" as Web
participant "Application Service" as App
database Database

User -> Web : Request
Web -> App : Execute operation
App -> Database : Read/write data
Database --> App : Result
App --> Web : Response
Web --> User : Display result
@enduml

15.1 Lợi ích

PlantUML có giá trị vì các sơ đồ có thể được:

• Lưu trữ bên cạnh mã nguồn

• Được xem xét trong các yêu cầu kéo (pull requests)

• Được tạo tự động

• Được cập nhật với các chỉnh sửa văn bản đơn giản

• Được bao gồm trong các quy trình xử lý Markdown hoặc tài liệu

• Được tạo ra nhất quán trên các môi trường khác nhau

15.2 Tổ chức các tệp PlantUML

Cấu trúc kho lưu trữ thực tế có thể là:

docs/
  architecture/
    system-context.puml
    components.puml
    deployment.puml
  workflows/
    place-order.puml
    refund-payment.puml
  domain/
    order-model.puml
    order-lifecycle.puml

Sử dụng tên mô tả và tổ chức các sơ đồ theo mục đích thay vì theo công cụ.

15.3 Giữ các hình ảnh đã tạo ra ngoài nguồn sự thật

Khi có thể:

• Lưu trữ .puml các tệp làm nguồn chính thống

• Tạo các tệp PNG, SVG hoặc PDF trong quá trình xây dựng tài liệu

• Tránh chỉnh sửa thủ công các hình ảnh đã tạo

• Xác minh rằng các sơ đồ được hiển thị thành công trong tự động hóa

15.4 Sử dụng phong cách nhất quán

Xác định một từ vựng trực quan nhỏ:

• Một màu cho các hệ thống bên ngoài

• Một màu cho các dịch vụ nội bộ

• Một màu cho cơ sở dữ liệu

• Một ký hiệu cho thông báo không đồng bộ

• Một quy ước đặt tên cho các giao diện

• Một cách để biểu diễn các ranh giới bảo mật

Sự nhất quán có giá trị hơn trang trí.

16. Mô hình hóa UML hỗ trợ bởi AI

AI có thể tăng tốc quá trình mô hình hóa, nhưng nó nên được coi là một trợ lý mô hình hóa chứ không phải là một thẩm quyền.

AI hữu ích cho:

• Chuyển đổi các yêu cầu thành các trường hợp sử dụng dự kiến

• Trích xuất các vai trò và mục tiêu

• Đề xuất các luồng hoạt động

• Tạo PlantUML

• Đề xuất các thành viên tham gia trong trình tự

• Xác định các thực thể của miền

• Phát hiện các đường dẫn thay thế bị thiếu

• Xem xét tính nhất quán của sơ đồ

• Tạo tài liệu từ các sơ đồ

• Chuyển đổi giữa các biểu diễn đồ họa và văn bản

• Tạo ý tưởng kiểm thử từ các chuyển đổi trạng thái

16.1 Một quy trình làm việc AI hiệu quả

Một quy trình làm việc đáng tin cậy là:

1. Cung cấp các yêu cầu, ràng buộc và ngữ cảnh hệ thống.

2. Yêu cầu AI xác định các giả định và sự không rõ ràng.

3. Tạo một sơ đồ dự kiến.

4. Xem xét sơ đồ đối chiếu với các yêu cầu thực tế.

5. So sánh nó với việc triển khai và cơ sở hạ tầng.

6. Sửa các chi tiết không chính xác hoặc được bịa đặt.

7. Hiển thị và kiểm tra kết quả trực quan.

8. Lấy ý kiến phản hồi từ các bên liên quan.

9. Lưu mô hình đã được phê duyệt vào kho lưu trữ dự án.

10. Cập nhật nó khi hệ thống thay đổi.

16.2 Gợi ý AI với các ràng buộc

Gợi ý yếu:

Tạo biểu đồ UML cho hệ thống đặt hàng.

Gợi ý mạnh hơn:

Tạo biểu đồ trình tự PlantUML cho việc gửi đơn hàng.

Các bên tham gia:
- Khách hàng
- Ứng dụng web
- Dịch vụ đơn hàng
- Nhà cung cấp thanh toán
- Dịch vụ tồn kho
- Cơ sở dữ liệu đơn hàng

Các ràng buộc:
- Thanh toán phải được ủy quyền trước khi đơn hàng được xác nhận.
- Việc đặt chỗ tồn kho có thể diễn ra song song với việc ủy quyền thanh toán.
- Thanh toán bị từ chối phải để trạng thái đơn hàng ở mức PaymentFailed.
- Thời gian chờ quá hạn nên được thử lại một lần.
- Hiển thị các đường dẫn thành công, bị từ chối và quá hạn.
- Không bịa đặt các dịch vụ không được liệt kê ở đây.

Các ràng buộc được nêu rõ ràng đến đâu thì khả năng đầu ra chứa kiến trúc không được hỗ trợ càng thấp đến đó.

16.3 Yêu cầu AI phê bình, không chỉ tạo ra

Các gợi ý đánh giá hữu ích bao gồm:

• Yêu cầu nào không được thể hiện?

• Các nhánh nào bị thiếu?

• Biểu đồ trình tự này có mâu thuẫn với máy trạng thái không?

• Có phụ thuộc nào chưa được giải thích không?

• Có trách nhiệm nào được giao cho thành phần không đúng không?

• Mô hình triển khai có hỗ trợ yêu cầu về tính sẵn sàng không?

• Chuyển đổi nào nên trở thành các trường hợp kiểm thử?

• Giả định nào cần được xác nhận?

16.4 Các lỗi mô hình hóa AI phổ biến

Các mô hình do AI tạo ra có thể:

• Bịa đặt các vai trò hoặc dịch vụ

• Nhầm lẫn giữa các vai trò kinh doanh và các thành phần kỹ thuật

• Thêm các bảng cơ sở dữ liệu không được hỗ trợ

• Giả định giao tiếp đồng bộ

• Bỏ sót các đường dẫn lỗi

• Thể hiện sai về quyền sở hữu

• Sử dụng các quan hệ UML không đúng cách

• Tạo ra các biểu đồ hợp lệ về mặt cú pháp nhưng sai về mặt ngữ nghĩa

• Trộn lẫn các mức trừu tượng hóa

• Xem các phỏng đoán như là các yêu cầu

Nguyên tắc cốt lõi là:

AI có thể tạo bản thảo nhanh chóng, nhưng chỉ có việc rà soát chuyên môn và kỹ thuật mới có thể xác định liệu bản thảo đó có chính xác hay không.

17. Xác thực UML so với thực tế

Một biểu đồ chỉ có giá trị khi nó vẫn được căn chỉnh với hệ thống.

17.1 Xác thực so với các yêu cầu

Kiểm tra:

• Mọi yêu cầu quan trọng có xuất hiện trong một hoặc nhiều mô hình không?

• Các vai diễn và mục tiêu có chính xác không?

• Các quy tắc kinh doanh có được biểu diễn không?

• Các trường hợp ngoại lệ có được bao gồm không?

• Các yêu cầu phi chức năng có được phản ánh ở những nơi phù hợp không?

17.2 Xác thực so với việc triển khai

Kiểm tra:

• Các ranh giới thành phần có khớp với mã nguồn không?

• Các đối tượng tham gia trong trình tự có tồn tại không?

• Các giao diện và thông điệp có chính xác không?

• Các trách nhiệm của lớp có thực tế không?

• Các hoạt động bất đồng bộ có được hiển thị chính xác không?

• Các chuyển đổi trạng thái có được thực thi bởi việc triển khai không?

17.3 Xác thực so với các hoạt động vận hành

Kiểm tra:

• Biểu đồ triển khai có thể thực sự được triển khai không?

• Các kết nối mạng có thực tế không?

• Các hệ thống bên ngoài có được biểu diễn không?

• Các cơ sở dữ liệu, hàng đợi, bộ đệm và kho lưu trữ có được bao gồm ở những nơi quan trọng không?

• Các giả định về lỗi và khả năng mở rộng có hợp lý không?

17.4 Xác thực qua các sơ đồ

Tìm kiếm các mâu thuẫn như:

• Một kịch bản sử dụng đặt tên cho một tác nhân không có trong ngữ cảnh hệ thống

• Một sơ đồ trình tự gọi một thành phần không được hiển thị trong kiến trúc

• Một máy trạng thái cho phép một chuyển đổi không được hỗ trợ bởi các quy tắc nghiệp vụ

• Một sơ đồ lớp hiển thị quan hệ một-nhiều trong khi cơ sở dữ liệu bắt buộc quan hệ một-một

• Một sơ đồ triển khai bỏ sót một dịch vụ được yêu cầu bởi các sơ đồ trình tự

• Một sơ đồ hoạt động hiển thị các hoạt động song song trong khi việc triển khai là tuần tự nghiêm ngặt

Tính nhất quán qua các sơ đồ thường quan trọng hơn chất lượng nghệ thuật của bất kỳ sơ đồ riêng lẻ nào.

18. Khả năng truy vết

Khả năng truy vết liên kết các mô hình với các yêu cầu, mã nguồn, bài kiểm tra và các tài sản vận hành.

Một chuỗi truy vết đơn giản có thể là:

Yêu cầu
  → Kịch bản sử dụng
    → Luồng hoạt động
      → Kịch bản trình tự
        → Thành phần
          → Triển khai
            → Bài kiểm tra tự động

Đối với một đối tượng miền có trạng thái:

Quy tắc nghiệp vụ
  → Chuyển đổi trạng thái
    → Điều kiện bảo vệ
      → Trường hợp kiểm thử

Khả năng truy vết không yêu cầu kết nối mọi phần tử với mọi phần tử khác. Hãy tập trung vào các mối quan hệ có giá trị cao:

• Hành vi quan trọng đối với an toàn

• Yêu cầu quy định

• Biện pháp kiểm soát bảo mật

• Các tích hợp quan trọng

• Các quy tắc nghiệp vụ phức tạp

• Các quyết định kiến trúc có rủi ro cao

19. Kiểm soát phiên bản và bảo trì mô hình

Một sơ đồ là tài liệu, và tài liệu trở nên không đáng tin cậy khi không được bảo trì.

19.1 Lưu trữ mô hình gần với công việc mà chúng mô tả

Các phương pháp khả thi bao gồm:

• Các tệp UML trong kho lưu trữ nguồn

• Kho lưu trữ tài liệu kiến trúc

• Một kho lưu trữ mô hình dùng chung

• Các sơ đồ được tạo ra được công bố cùng với tài liệu kỹ thuật

• Mối liên kết giữa các yêu cầu và các phần tử mô hình

19.2 Xem lại các biểu đồ cùng với mã nguồn

Đối với các thay đổi về kiến trúc hoặc hành vi, hãy bao gồm cập nhật biểu đồ liên quan trong cùng một thay đổi với việc triển khai khi khả thi.

Người xem lại sau đó có thể đánh giá:

• Liệu việc triển khai có khớp với thiết kế dự định hay không

• Liệu thay đổi thiết kế đã hoàn tất hay chưa

• Liệu các phụ thuộc đã thay đổi hay chưa

• Liệu có tồn tại các đường dẫn lỗi mới hay không

• Liệu các hệ quả triển khai đã được xem xét hay chưa

19.3 Ưu tiên ít biểu đồ có tính xác thực hơn

Nhiều biểu đồ mâu thuẫn nhau còn tệ hơn một biểu đồ chưa hoàn chỉnh. Hãy xác định biểu đồ nào là có tính xác thực cho từng mối quan tâm.

Ví dụ:

• Biểu đồ thành phần: có tính xác thực đối với các ranh giới dịch vụ chính

• Biểu đồ triển khai: có tính xác thực đối với cấu hình sản xuất

• Máy trạng thái: có tính xác thực đối với vòng đời đơn hàng

• Biểu đồ lớp: có tính xác thực đối với các mối quan hệ trong miền

20. Những lỗi mô hình hóa phổ biến

Mô hình hóa mọi thứ

Nhiều biểu đồ hơn không tự động tạo ra sự hiểu biết nhiều hơn. Hãy mô hình hóa các rủi ro và quyết định quan trọng.

Trộn lẫn các mức trừu tượng

Đừng đặt các vai trò kinh doanh, lớp lập trình, cơ sở hạ tầng đám mây và các cột cơ sở dữ liệu vào cùng một biểu đồ không phân biệt.

Sử dụng tên không rõ ràng

Các tên như “Xử lý Dữ liệu” hoặc “Xử lý Yêu cầu” che giấu ý định. Hãy ưu tiên các tên xác định mục tiêu, trách nhiệm hoặc sự kiện có ý nghĩa.

Bỏ sót hành vi lỗi

Các mô hình chỉ tập trung vào thành công tạo ra những kỳ vọng không thực tế. Hãy bao gồm các ngoại lệ quan trọng, các lần thử lại, thời gian chờ và các trạng thái bị từ chối.

Xem các biểu đồ là vĩnh viễn

Kiến trúc luôn thay đổi. Một biểu đồ cần có chủ sở hữu và kỳ vọng về việc bảo trì.

Sử dụng quá mức các quan hệ UML

Một quan hệ đơn giản thường tốt hơn một tập hợp các loại quan hệ chính xác về mặt kỹ thuật nhưng gây nhầm lẫn.

Làm cho các biểu đồ khó đọc

Sử dụng nhiều chế độ xem tập trung thay vì một sơ đồ khổng lồ duy nhất. Chia nhỏ các mô hình lớn theo kịch bản, phân hệ, vòng đời hoặc ranh giới triển khai.

Cho phép công cụ dẫn dắt thiết kế

Công cụ có thể giúp vẽ sơ đồ dễ dàng hơn, nhưng không thể quyết định những gì cần được mô hình hóa hay liệu mô hình có chính xác hay không.

21. Quy trình mô hình hóa thực tiễn

Một nhóm có thể áp dụng quy trình sau cho một tính năng hoặc hệ thống.

Bước 1: Xác định phạm vi

Tạo một chế độ xem ngữ cảnh nhẹ và xác định:

• Ranh giới hệ thống

• Người dùng chính

• Hệ thống bên ngoài

• Mục tiêu chính

Bước 2: Xác định các trường hợp sử dụng

Viết các trường hợp sử dụng dưới dạng mục tiêu của các vai trò. Nhóm các chức năng liên quan và xác định các kịch bản quan trọng nhất.

Bước 3: Mô hình hóa quy trình làm việc chính

Sử dụng sơ đồ hoạt động để hiển thị:

• Luồng bình thường

• Các quyết định

• Trách nhiệm

• Công việc song song

• Các trường hợp ngoại lệ

Bước 4: Chọn các kịch bản quan trọng

Tạo sơ đồ trình tự cho các tương tác quan trọng, phức tạp, rủi ro cao hoặc đòi hỏi tích hợp nhiều.

Bước 5: Xác định cấu trúc miền

Tạo sơ đồ lớp ở mức khái niệm hoặc thiết kế cho các khái niệm liên quan đến các kịch bản đó.

Bước 6: Xác định ranh giới kiến trúc

Sử dụng sơ đồ thành phần để hiển thị:

• Các mô-đun hoặc dịch vụ chính

• Các giao diện

• Các phụ thuộc

• Quyền sở hữu

• Điểm tích hợp

Bước 7: Triển khai mô hình

Tạo sơ đồ triển khai khi cơ sở hạ tầng, bảo mật, khả năng mở rộng, tính sẵn sàng hoặc vận hành là những mối quan tâm đáng kể.

Bước 8: Vòng đời mô hình

Tạo sơ đồ máy trạng thái cho các thực thể mà hành vi của chúng phụ thuộc vào trạng thái hoặc các chuyển đổi được phép.

Bước 9: Xác thực

So sánh các mô hình với:

• Yêu cầu

• Mã nguồn hiện có

• Bài kiểm tra

• Cấu trúc dữ liệu

• Cơ sở hạ tầng

• Ràng buộc vận hành

Bước 10: Bảo trì

Cập nhật các sơ đồ bị ảnh hưởng khi hành vi, giao diện, quyền sở hữu hoặc triển khai thay đổi.

22. Sản phẩm tối thiểu cho một hệ thống điển hình

Đối với một ứng dụng quy mô trung bình, một cơ sở thực tế có thể là:

• Một sơ đồ ngữ cảnh hệ thống hoặc xem xét trường hợp sử dụng

• Từ hai đến năm sơ đồ hoạt động cho các quy trình kinh doanh quan trọng

• Từ hai đến năm sơ đồ trình tự cho các kịch bản quan trọng

• Một sơ đồ lớp miền

• Một sơ đồ thành phần

• Một sơ đồ triển khai sản xuất

• Sơ đồ máy trạng thái cho các thực thể vòng đời chính

Đây không phải là một hạn mức bắt buộc. Một số hệ thống có thể cần ít sơ đồ hơn; những hệ thống khác có thể cần nhiều hơn. Số lượng phù hợp phụ thuộc vào độ phức tạp, rủi ro, quy mô nhóm, quy định và chi phí của sự hiểu lầm.

23. Chiến lược lựa chọn công cụ

Các công cụ khác nhau phục vụ các nhu cầu mô hình hóa khác nhau.

Một nhóm không cần chọn một công cụ duy nhất cho mọi tình huống. Một cách tiếp cận hỗn hợp có thể hoạt động tốt nếu nguồn sự thật và trách nhiệm bảo trì được làm rõ.

Kết luận

Chiến lược UML thực tế không phải là sử dụng mọi loại biểu đồ. Đó là việc chọn tập hợp nhỏ nhất các góc nhìn giúp hệ thống trở nên dễ hiểu.

Hạt nhân bảy biểu đồ cung cấp phạm vi bao phủ rộng:

• Biểu đồ trường hợp sử dụng giải thích mục tiêu và phạm vi.

• Biểu đồ hoạt động giải thích quy trình làm việc và trách nhiệm.

• Biểu đồ trình tự giải thích sự cộng tác và thời gian.

• Biểu đồ lớp giải thích cấu trúc và các khái niệm miền.

• Biểu đồ thành phần giải thích các ranh giới kiến trúc.

• Biểu đồ triển khai giải thích vị trí thời gian chạy và cơ sở hạ tầng.

• Biểu đồ máy trạng thái giải thích các quy tắc vòng đời.

Visual Paradigm có thể hỗ trợ mô hình hóa đồ họa, khả năng truy vết và cộng tác dựa trên kho lưu trữ. VPasCode và PlantUML giúp biểu đồ dễ dàng kiểm soát phiên bản, xem xét, tạo ra và bảo trì cùng với mã nguồn. AI có thể tăng tốc việc soạn thảo, chuyển đổi và xem xét, nhưng đầu ra của nó phải được kiểm tra đối chiếu với các yêu cầu thực tế, việc triển khai thực tế và các ràng buộc vận hành.

Thực hành mô hình hóa mạnh mẽ nhất là có kỷ luật thay vì toàn diện:

1. Mô hình hóa các quyết định, rủi ro và hành vi quan trọng.

2. Chọn loại biểu đồ trả lời câu hỏi tốt nhất.

3. Giữ cho mỗi sơ đồ tập trung vào một mức độ trừu tượng duy nhất.

4. Kết nối các sơ đồ liên quan thông qua tên gọi nhất quán và khả năng truy vết.

5. Xác thực các mô hình dựa trên yêu cầu, mã nguồn, bài kiểm thử và quá trình triển khai.

6. Lưu trữ và xem xét các sơ đồ như các tài sản dự án có thể bảo trì.

7. Xóa các sơ đồ không còn mang lại giá trị.

UML hiệu quả không được đo bằng số lượng sơ đồ được tạo ra. Nó được đo bằng việc các mô hình có giúp mọi người xây dựng, kiểm thử, vận hành và thay đổi hệ thống với sự tự tin cao hơn hay không.

Tài liệu tham khảo

1. VPasCode: Sơ đồ dưới dạng mã được hỗ trợ bởi AI với PlantUML, Mermaid và Graphviz: Hướng dẫn chính thức bao gồm công cụ chuyển đổi văn bản sang sơ đồ của VPasCode, các thực hành tốt nhất về cú pháp và quy trình chỉnh sửa được hỗ trợ bởi AI.
2. Từ “Việc vẽ sơ đồ” đến “Diễn giải”: Tổng quan về Trợ lý ảo AI: Giải thích cách Trợ lý ảo AI của Visual Paradigm chuyển đổi ngôn ngữ tự nhiên thành các sơ đồ UML và các loại sơ đồ khác tuân thủ tiêu chuẩn.
3. Tăng cường Trợ lý ảo AI của Visual Paradigm với Cơ sở kiến thức NotesKeep: Hướng dẫn cách kết nối các kho lưu trữ NotesKeep làm nguồn kiến thức cho việc tạo sơ đồ và tổng hợp yêu cầu dựa trên AI.
4. Cách mạng hóa việc mô hình hóa UML trên Mac của bạn với Visual Paradigm: Tổng quan về hỗ trợ UML 2.x, kỹ thuật mã nguồn và khả năng truy vết mô hình của Visual Paradigm trên macOS.
5. Giới thiệu Trợ lý ảo AI VPP trong Visual Paradigm 18.1: Thông báo phát hành Trợ lý ảo AI VPP cho phép người dùng truy vấn các tệp dự án .vpp thông qua ngôn ngữ tự nhiên.
6. Gói dịch vụ và giá cả của VPasCode: So sánh giá cả và tính năng cho gói miễn phí của VPasCode và khả năng tích hợp với các phiên bản Online/Desktop của Visual Paradigm.
7. Chào mừng đến với Visual Paradigm VPasCode: Sự chuyển dịch sang Sơ đồ dưới dạng mã: Giới thiệu quy trình làm việc Sơ đồ dưới dạng mã và môi trường hiển thị thống nhất cho PlantUML, Mermaid và Graphviz.
8. Tạo sơ đồ AI bản địa trong Visual Paradigm VPasCode: Chi tiết về AI nhúng của VPasCode, cho phép tạo và chỉnh sửa các sơ đồ PlantUML/Mermaid/Graphviz trực tiếp trong trình soạn thảo.

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