Biểu đồ lớp UML cho mô hình hóa dữ liệu với PlantUML

Một biểu đồ lớp UML mô tả cấu trúc của một hệ thống: những thứ mà nó mô hình hóa, các thuộc tính của chúng và cách chúng liên quan. Đối với mô hình hóa dữ liệu, nó có thể nắm bắt các khái niệm miền và các ràng buộc trước khi bạn quyết định sử dụng các bảng hoặc mã ứng dụng.

PlantUML giúp biểu đồ có thể tái tạo: bạn viết văn bản, hiển thị nó, xem xét các thay đổi trong kiểm soát phiên bản và cập nhật nó khi mô hình phát triển. Nó bổ sung—not thay thế—các lược đồ cơ sở dữ liệu, các bản di chuyển và các quy tắc kinh doanh chi tiết.

1. Chọn mức độ mô hình hóa

Một biểu đồ mô hình hóa dữ liệu hữu ích thường tập trung vào một mức độ tại một thời điểm:

• Khái niệm: các khái niệm kinh doanh và các mối quan hệ, với tối thiểu chi tiết kỹ thuật. Ví dụ: Khách hàng đặt Đơn hàng.

• Logic: các thuộc tính, định danh, số lượng và các quy tắc, mà không gắn mô hình với một cơ sở dữ liệu cụ thể.

• Vật lý: các chi tiết triển khai như các kiểu cột SQL, các chỉ mục và các ràng buộc cụ thể cho cơ sở dữ liệu.

Ví dụ dưới đây là một mô hình miền logic. Các kiểu như UUID, Tiền, và DateTime chỉ mang tính minh họa; hãy quyết định các biểu diễn cụ thể của chúng khi chọn công nghệ.

2. Nền tảng của PlantUML

Một lớp có tên và có thể liệt kê các thuộc tính và thao tác:

@startuml
class Customer {
  -id: UUID
  +name: String
  +email: String
  +changeEmail(newEmail: String): void
}
@enduml

Các dấu hiệu hiển thị là các gợi ý mô hình hóa tùy chọn:

• + công khai

• - riêng tư

• # được bảo vệ

• ~ hiển thị gói

Đối với sơ đồ miền hoặc sơ đồ dữ liệu, các thuộc tính là quan trọng nhất. Chỉ bao gồm các thao tác khi chúng làm rõ hành vi quan trọng; tránh biến sơ đồ thành một danh sách mã đầy đủ.

3. Mối quan hệ và tính đa trị

Các ký hiệu mối quan hệ hữu ích nhất cho mô hình hóa dữ liệu là:

Nhãn đa số nằm gần các đầu của mối liên kết:

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

• 0..1 — tùy chọn, tối đa một

• * hoặc 0..* — không hoặc nhiều

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

• 2..5 — một phạm vi bị giới hạn

Ví dụ:

Khách hàng "1" -- "0..*" Đơn hàng : đặt

Hãy đọc kỹ các nhãn ở hai đầu: một khách hàng có thể đặt không hoặc nhiều đơn hàng; mỗi đơn hàng được liên kết với đúng một khách hàng. Các nhãn mô tả mối quan hệ, không nhất thiết là cách triển khai khóa ngoại cụ thể của một cơ sở dữ liệu.

4. Ví dụ minh họa: cửa hàng trực tuyến

Mô hình này bao gồm khách hàng, đơn hàng, dòng đơn hàng, sản phẩm và ghi chép thanh toán. Nó minh họa các định danh, các kiểu dữ liệu giống giá trị, một kiểu liệt kê, thành phần (composition) và các bội số.

@startuml ShopDomain
skinparam classAttributeIconSize 0
skinparam shadowing false

hide methods

class Customer {
  +customerId: UUID
  +email: EmailAddress
  +displayName: String
}

class Order {
  +orderId: UUID
  +placedAt: DateTime
  +status: OrderStatus
  +total: Money
}

class OrderLine {
  +lineNumber: Integer
  +quantity: PositiveInteger
  +unitPrice: Money
}

class Product {
  +productId: UUID
  +sku: SKU
  +name: String
  +currentPrice: Money
}

class Payment {
  +paymentId: UUID
  +amount: Money
  +status: PaymentStatus
  +paidAt: DateTime [0..1]
}

class Money <<value object>> {
  +amount: Decimal
  +currency: CurrencyCode
}

enum OrderStatus {
  DRAFT
  PLACED
  PAID
  FULFILLED
  CANCELLED
}

enum PaymentStatus {
  PENDING
  AUTHORIZED
  CAPTURED
  FAILED
  REFUNDED
}

Customer "1" -- "0..*" Order : places
Order "1" *-- "1..*" OrderLine : contains
OrderLine "0..*" --> "1" Product : refers to
Order "1" -- "0..*" Payment : payment attempts
Order --> OrderStatus
Payment --> PaymentStatus
OrderLine --> Money : unit price
Payment --> Money : amount

note right of OrderLine
  quantity must be greater than zero
  unitPrice is the price captured
  when the order is placed
end note

note right of Product
  Product.currentPrice may change.
  It does not replace OrderLine.unitPrice.
end note
@enduml

Tại sao mô hình hóa OrderLine một cách rõ ràng? Mối quan hệ giữa một đơn hàng và một sản phẩm có dữ liệu riêng—số lượng và giá tại thời điểm mua. Điều đó biến nó thành một khái niệm trong miền nghiệp vụ, không chỉ là một liên kết đơn thuần.

Tại sao sử dụng thành phần (composition) từ Order đến OrderLine? Ví dụ giả định rằng một dòng đơn hàng thuộc về một đơn hàng và không có ý nghĩa độc lập. Chỉ sử dụng thành phần (composition) khi quy tắc sở hữu và vòng đời đó đúng trong miền nghiệp vụ của bạn; ký hiệu UML không bắt buộc điều này trong cơ sở dữ liệu.

Tại sao phân biệt giá hiện tại và giá lịch sử? Giá của một sản phẩm có thể thay đổi sau khi đơn hàng được đặt. Việc giữ lại giá tại thời điểm mua trên dòng đơn hàng giúp bảo tồn số tiền lịch sử.

5. Các quyết định mô hình hóa quan trọng

Các định danh: Đánh dấu các định danh một cách thống nhất, chẳng hạn như customerId hoặc orderId. UML không định nghĩa một ký hiệu duy nhất phổ quát cho các khóa chính, vì vậy hãy chọn một quy ước và tài liệu hóa nó. Một stereotype hoặc ghi chú có thể làm cho nó rõ ràng:

class Customer {
  +customerId: UUID <<PK>>
  +email: EmailAddress
}

Giá trị tùy chọn: Sử dụng [0..1] cho một thuộc tính tùy chọn khi điều đó rõ ràng đối với người đọc của bạn, hoặc ghi chú quy tắc. Ví dụ, một khoản thanh toán có thể không có paidAt dấu thời gian cho đến khi nó thành công.

Đối tượng giá trị: Một kiểu như Money hoặc EmailAddress có thể đại diện cho một khái niệm có xác thực hoặc ngữ nghĩa riêng. Hãy quyết định xem nó nên xuất hiện dưới dạng một lớp riêng biệt, một kiểu thuộc tính, hay một cấu trúc cơ sở dữ liệu dựa trên đối tượng mục tiêu và mức độ chi tiết.

Kiểu liệt kê và giá trị được kiểm soát: Sử dụng kiểu liệt kê khi tập hợp các giá trị cho phép là nhỏ và tương đối ổn định. Nếu các giá trị cần mô tả độc lập, vòng đời hoặc quản lý, hãy mô hình hóa chúng dưới dạng một lớp thay thế.

Chuẩn hóa và triển khai: Một biểu đồ lớp truyền đạt các khái niệm và quy tắc; nó không giải quyết mọi chi tiết quan hệ. Ví dụ, việc Money có trở thành hai cột, một bảng riêng biệt, hay một kiểu cụ thể cho cơ sở dữ liệu là một quyết định về triển khai.

Giữ cho các biểu đồ dễ đọc: Chia một miền lớn thành các biểu đồ tập trung—như đặt hàng, tồn kho và danh tính—và sử dụng các gói để nhóm các lớp liên quan. Chỉ hiển thị các thuộc tính liên quan đến câu hỏi mà biểu đồ được thiết kế để trả lời.

6. Xây dựng mô hình từ các yêu cầu

1. Trích xuất các khái niệm ứng viên từ ngôn ngữ miền: danh từ thường gợi ý các lớp; động từ thường gợi ý các mối quan hệ hoặc hành vi.

2. Làm rõ các quy tắc với các câu hỏi cụ thể: Một đơn hàng có thể tồn tại mà không có khách hàng không? Nó có thể có không có dòng nào không? Một khoản thanh toán có thể được thử lại không?

3. Chọn mức độ mô hình hóa và giữ các quyết định kỹ thuật về cơ sở dữ liệu ra khỏi sơ đồ khái niệm.

4. Thêm các thuộc tính và định danh chỉ khi chúng giúp giải thích mô hình.

5. Đặt các bội số từ các quy tắc kinh doanh, kiểm tra cả hai đầu của mọi mối quan hệ.

6. Xem xét các trường hợp biên: xóa, hồ sơ lịch sử, các trường tùy chọn, các lần thử lặp lại và các giá trị thay đổi.

7. Hiển thị và xem xét sơ đồ với các chuyên gia miền và người thực hiện. Hãy coi nó như một mô hình để xác thực, không chỉ là một hình ảnh để phê duyệt.

7. Sử dụng VPasCode và Visual Paradigm

VPasCode là một trình soạn thảo văn bản sang sơ đồ dựa trên trình duyệt có hỗ trợ PlantUML và xem trước trực tiếp. Mô tả tính năng của nó cũng liệt kê việc tạo và sửa đổi mã sơ đồ bằng AI, cũng như hỗ trợ cú pháp. Một quy trình làm việc thực tế là:

1. Mở VPasCode và chọn hoặc nhập PlantUML.

2. Dán ví dụ ở trên và kiểm tra sơ đồ đã được hiển thị.

3. Lặp lại trên mã nguồn PlantUML; giữ văn bản như một sản phẩm có thể quản lý phiên bản.

4. Sử dụng trợ lý AI, nếu có trong không gian làm việc của bạn, để soạn thảo hoặc sửa đổi bản nháp đầu tiên.

5. Tự mình xác minh mọi lớp, mối quan hệ, bội số và quy tắc kinh doanh được tạo ra.

Các công cụ sơ đồ hỗ trợ AI của Visual Paradigm có thể tạo các sơ đồ có thể chỉnh sửa từ các mô tả bằng ngôn ngữ tự nhiên. Quy trình làm việc được công bố của nó mô tả việc tạo sơ đồ lớp từ một lời nhắc, sau đó tinh chỉnh các phần tử và mối quan hệ của nó. Hãy coi đầu ra của AI là mộtbản nháp: nó có thể suy luận sai về quyền sở hữu, thiếu các ràng buộc hoặc các lớp không được biện minh. Tính đúng đắn của mô hình vẫn phụ thuộc vào việc xác thực nó đối với các yêu cầu.

Ví dụ, hãy đưa ra lời nhắc cho trợ lý AI như sau:

Tạo một sơ đồ lớp UML logic cho một cửa hàng trực tuyến. Khách hàng đặt hàng. Mỗi đơn hàng chứa một hoặc nhiều dòng đơn hàng. Mỗi dòng đơn hàng tham chiếu đến một sản phẩm và lưu trữ số lượng và đơn giá tại thời điểm mua. Đơn hàng có thể có nhiều lần thử thanh toán. Bao gồm các định danh, bội số và các bản liệt kê trạng thái đơn hàng và thanh toán. Chỉ xuất ra PlantUML.

Sau đó, hãy xem xét đầu ra đối với các yêu cầu trước khi chấp nhận nó. Để có kết quả tốt hơn, hãy nêu rõ các giả định một cách cụ thể—ví dụ, liệu đơn hàng có thể là bản nháp không có dòng nào không, và liệu thanh toán có thể được hoàn tiền không.

Visual Paradigm mô tảVPasCode dưới dạng trình soạn thảo hỗ trợ PlantUML với khả năng hiển thị trực tiếp và tạo hoặc chỉnh sửa được hỗ trợ bởi AI. Các công cụ và tính khả dụng có thể thay đổi tùy theo phiên bản sản phẩm hoặc không gian làm việc.

8. Danh sách kiểm tra rà soát ngắn gọn

Trước khi chia sẻ hoặc triển khai sơ đồ lớp, hãy kiểm tra:

• Mỗi lớp có đại diện cho một khái niệm miền có ý nghĩa không?

• Các định danh và các thuộc tính quan trọng có rõ ràng không?

• Các nhãn quan hệ và tính đa trị có chính xác tại cả haiđầu mút không?

• Sự hợp thành có phản ánh đúng sự phụ thuộc vòng đời thực tế không?

• Các sự kiện lịch sử có được bảo tồn ở những nơi giá trị hiện tại có thể thay đổi không?

• Các giá trị tùy chọn và các ràng buộc kinh doanh có được hiển thị rõ ràng không?

• Sơ đồ có đủ tập trung cho đối tượng mục tiêu của nó không?

• Nội dung đã được tạo ra đã được kiểm tra so với các yêu cầu thực tế chưa?

Quy trình sơ đồ dưới dạng mã tốt nhất là AI để tạo bản nháp ban đầu, PlantUML để chỉnh sửa chính xác và quản lý lịch sử phiên bản, và rà soát của con người để đảm bảo tính chính xác của miền.

This post is also available in Deutsch, English, Español, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, 简体中文 and 繁體中文.