Sơ đồ lớp là gì?
Một Sơ đồ lớp là một sơ đồ UML giúp trực quan hóa kiến trúc tĩnh của một hệ thống phần mềm hướng đối tượng. Là một loại sơ đồ UML không thể thiếu,loại sơ đồ UML, nó mô tả các lớp, giao diện và mô hình dữ liệu riêng lẻ trong ứng dụng của bạn, ghi rõ các trường nội bộ (thuộc tính), các chức năng hoạt động (phương thức) và các mối quan hệ cấu trúc kết nối chúng lại với nhau. Bản vẽ này rất quan trọng đối với các kỹ sư phần mềm cần chuyển đổi các thiết kế miền cấp cao thành các cấu trúc đối tượng sạch sẽ, dễ bảo trì.
Với Mermaid.js, bạn có thể phác thảo các mô hình dữ liệu và dịch vụ hệ thống bằng các định nghĩa trực quan, dựa trên văn bản. Bộ động lực bố cục tự động tính toán kích thước hộp, cấu trúc các ngăn dữ liệu UML chuẩn, và căn chỉnh các mũi tên quan hệ trên bảng vẽ của bạn mà không cần bất kỳ thao tác định dạng thủ công nào.
Hướng dẫn cú pháp cốt lõi: Các thành phần và cấu trúc
Để thiết kế một sơ đồ lớp UML chính xác, tuân thủ chuẩn trong Mermaid, bạn phải thành thạo các khai báo thành viên, các bộ sửa truy cập và các mũi tên mối quan hệ cấu trúc.
1. Khai báo lớp và các ngăn lớp
Bạn có thể định nghĩa một lớp bằng hai định dạng hợp lệ. Đối với một lớp đơn giản, hãy sử dụng từ khóa classkèm theo tên lớp. Nếu bạn muốn bao gồm các trường và phương thức ngay lập tức, hãy sử dụng dấu ngoặc nhọn ở cuối để tạo khối thân rõ ràng:
classDiagram
class UserProfile {
+String username
+String email
+updateEmail(newEmail) void
}
2. Thêm các bộ sửa mức độ truy cập / quyền truy cập
Để ghi chú các quy tắc đóng gói UML chuẩn, hãy đặt một ký hiệu cụ thể ngay trước tên thuộc tính hoặc phương thức để xác định mức độ truy cập của nó:
+**Công khai:** Có thể truy cập từ bất kỳ lớp nào khác.-**Riêng tư:** Chỉ có thể truy cập bên trong lớp khai báo.#**Bảo vệ:** Có thể truy cập trong lớp và các lớp con của nó.~**Gói / Nội bộ:** Có thể truy cập trong giới hạn cùng gói.
classDiagram
class BankAccount {
-double balance
#String accountHolder
+getBalance() double
}
3. Thành thạo các mũi tên quan hệ và liên kết kế thừa
Để thể hiện cách các lớp tương tác trong mô hình sơ đồ UML của bạn, hãy kết nối các ID của chúng bằng các chuỗi quan hệ chuyên dụng. Trong Mermaid, hướng của đường nối có ý nghĩa: đầu mũi tên chỉ về lớp cha hoặc lớp chứa.
- Kế thừa / Tổng quát hóa (Mũi tên gạch hoặc mũi tên liền):
Child --|> Parent(Biểu diễn mối quan hệ “là một”). - Thực hiện / Triển khai:
Class ..|> Interface(Biểu diễn một lớp thực hiện hợp đồng giao diện). - Thành phần (Kim cương liền):
Child --* Parent(Biểu diễn quyền sở hữu nghiêm ngặt; nếu cha chết, con cũng chết). - Tổng hợp (Kim cương trong suốt):
Child --o Parent(Biểu diễn mối quan hệ tập hợp lỏng lẻo; con có thể tồn tại độc lập). - Phụ thuộc:
ClassA ..> ClassB(Biểu diễn một tham chiếu tạm thời tại thời điểm chạy).
classDiagram
Car --|> Vehicle : "Kế thừa từ"
Engine --* Car : "Là một phần của"
Các thực hành tốt nhất cho bố cục kiến trúc lớp sạch sẽ
- Sắp xếp các thành viên lớp theo hình thức trực quan: Luôn nhóm các biến lớp ở đầu khối thân và các hàm ở cuối. Bố cục này phù hợp với cấu trúc lớp tiêu chuẩn trong IDE và giúp sơ đồ của bạn dễ đọc ngay lập tức.
- Xác định kiểu trả về: Khi khai báo phương thức, thêm kiểu trả về vào cuối dòng phương thức (ví dụ,
+fetchData() DataSet). Điều này cung cấp cho đội ngũ kỹ thuật của bạn bối cảnh triển khai chính xác. - Giữ rõ ràng tính đa dạng: Để chỉ số lượng mảng hoặc kích thước bộ sưu tập, thêm các chuỗi văn bản đa dạng trực tiếp vào bao bọc dòng quan hệ (ví dụ,
Customer "1" --o "many" Order).
Ví dụ về sơ đồ lớp Mermaid.js trong thế giới thực
Ví dụ 1: Hệ thống con miền Cổng thanh toán (Bao đóng & Giao diện)
Bản thiết kế chức năng này mô hình hóa một dịch vụ miền thanh toán trực tuyến. Nó minh họa cách sử dụng các bộ giới hạn truy cập, nhóm các thành viên lớp và triển khai các mối quan hệ giao diện một cách sạch sẽ.
classDiagram
class PaymentProcessor {
<<interface>>
+processPayment(amount) boolean
+refundPayment(txnId) boolean
}
class StripeGateway {
-String apiKey
-String endpointUrl
+processPayment(amount) boolean
+refundPayment(txnId) boolean
-logTransaction(status) void
}
class PayPalGateway {
-String merchantId
+processPayment(amount) boolean
+refundPayment(txnId) boolean
}
StripeGateway ..|> PaymentProcessor : "Thực hiện"
PayPalGateway ..|> PaymentProcessor : "Thực hiện"
Phân tích cú pháp: Mã <<interface>> thẻ này rõ ràng đánh dấu `PaymentProcessor` là một hợp đồng kiến trúc cấp cao. Hai lớp triển khai cổng cụ thể sử dụng các trường riêng tư (-apiKey) cho các thông tin xác thực nhạy cảm, trong khi công khai các thao tác thanh toán công khai (+processPayment) được liên kết thông qua mũi tên thực hiện (..|>).
Ví dụ 2: Bộ xử lý đơn hàng doanh nghiệp (Thành phần & Đa dạng)
Bản thiết kế hệ thống nâng cao này mô phỏng một lược đồ quản lý đơn hàng thương mại điện tử phức tạp, minh họa cách ghi chú về quyền sở hữu cấu trúc và số lượng đối tượng qua nhiều lớp liên kết với nhau.
classDiagram
class Customer {
+int customerId
+String name
+placeOrder() Order
}
class Order {
+int orderId
+Date dateCreated
-String internalStatus
+calculateTotal() double
}
class OrderItem {
+int itemId
+int quantity
+double pricePerUnit
}
class Address {
+String street
+String city
+String postalCode
}
Customer "1" --o "many" Order : "chủ sở hữu"
OrderItem "1..*" --* "1" Order : "thành phần"
Address "1" --> Order : "gửi đến"
Phân tích cú pháp: Ví dụ này minh họa sự khác biệt giữa tích hợp và kết hợp. Mũi tên hình kim cương đậm (--*) cho thấy rằng một `OrderItem` được liên kết chặt chẽ với một `Order` (nếu một đơn hàng bị xóa, các mục chi tiết riêng lẻ của nó cũng sẽ bị hủy). Ngược lại, mũi tên hình kim cương rõ ràng (--o) cho biết rằng một `Customer` sở hữu nhiều đơn hàng, nhưng cả hai thực thể này đều có thể tồn tại độc lập. Các chuỗi bội số (như "1..*") xác định các yêu cầu liên quan của hệ thống.