PlantUML を用いたデータモデリングのための UML クラス図

AUML クラス図は、構造を記述します：システムがモデル化するもの、それらの属性、およびそれらの関係です。データモデリングにおいては、テーブルやアプリケーションコードに着手する前に、ドメインの概念と制約を捉えることができます。

PlantUMLは図を再現可能にします：テキストを書き、レンダリングし、バージョン管理で変更を確認し、モデルが進化するにつれて更新します。これはデータベーススキーマ、マイグレーション、詳細なビジネスルールを代替するものではなく、補完するものです。

1. モデリングレベルを選択する

有用なデータモデリング図は、通常、一度に一つのレベルに焦点を当てます：

• 概念レベル：ビジネス概念と関係性を、技術的な詳細を最小限に抑えて記述します。例：顧客が注文.

• 論理レベル：属性、識別子、多重度、およびルールを記述しますが、モデルを特定のデータベースに結びつけません。

• 物理レベル：SQL の列型、インデックス、およびデータベース固有の制約などの実装詳細を記述します。

以下の例は論理ドメインモデルです。UUID, Money、およびDateTimeは例示的なものです。技術を選択する際に、それらの具体的な表現を決定してください。

2. PlantUML の基礎

クラスには名前があり、属性と操作をリストできる：

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

可視性マーカはオプションのモデリングヒントです：

• + public

• - private

• # protected

• ~パッケージ可視性

ドメイン図またはデータ図の場合、属性が最も重要です。重要な振る舞いを明確にする場合のみ操作を含め、図が完全なコードリストにならないようにしてください。

3. リレーションシップと多重度

データモデリングに最も有用なリレーションシップ記法は次の通りです：

多重度ラベルは関連の端の近くに配置されます:

• 1 — ちょうど 1 つ

• 0..1 — オプション、最大 1 つ

• * または 0..* — 0 以上

• 1..* — 1 以上

• 2..5 — 範囲が制限された値

例:

Customer "1" -- "0..*" Order : 配置

両端のラベルを注意深く読んでください：1 人の顧客は 0 件以上の注文を発生させることができますが、各注文はちょうど 1 人の顧客に関連付けられます。ラベルは関係性を記述するものであり、必ずしも特定のデータベースにおける外部キーの実装を意味するものではありません。

4. 具体例：オンラインショップ

このモデルには、顧客、注文、明細、商品、および支払い記録が含まれます。これは、識別子、値のような型、列挙型、合成、多重度を示しています。

@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

なぜモデル化OrderLineするのか？注文と商品の関係には、数量や購入時の価格といった独自のデータがあります。これは単なる単純なリンクではなく、ドメイン概念です。

なぜOrderからOrderLine?この例では、明細は 1 つの注文に属し、独立して意味を持つものではないと仮定しています。ドメインにおいてその所有権とライフサイクルのルールが真である場合にのみ合成を使用してください。UML 記法はデータベース上でそれを強制するものではありません。

なぜ現在の価格と過去の価格を区別するのか？商品の価格は注文が確定した後で変更される可能性があります。明細に購入時の価格を保持することで、過去の金額が保存されます。

5. 重要なモデル化の判断

識別子：識別子を一貫してマークしてください。例えばcustomerIdやorderId. UML は主キーに対する単一の普遍的な表記法を定義していないため、規約を選択して文書化してください。ステレオタイプまたは注釈を用いて明示することができます：

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

オプション値： を使用[0..1] オプション属性として使用します（これが読者に明確な場合）か、またはルールを注記してください。例えば、支払いにはpaidAt タイムスタンプが成功するまで存在しない場合があります。

値オブジェクト： のような型はMoney またはEmailAddress 独自の検証や意味論を持つ概念を表すことができます。対象読者と詳細レベルに基づいて、それが別個のクラス、属性型、またはデータベース構造として現れるべきかを決定してください。

列挙型と制御値： 許可されたセットが小さく比較的安定している場合は列挙型を使用してください。値に独立した説明、ライフサイクル、または管理が必要な場合は、代わりにクラスとしてモデル化してください。

正規化と実装： クラス図は概念とルールを伝達しますが、すべての関係詳細を決定するものではありません。例えば、Money が2つの列、別々のテーブル、またはデータベース固有の型になるかは実装の判断です。

図を読みやすく保つ： 大規模なドメインを注文、在庫、ID といった焦点を絞った図に分割し、パッケージを使用して関連するクラスをグループ化してください。図が答えようとしている質問に関連する属性のみを表示してください。

6. 要件からモデルを構築する

1. 候補となる概念を抽出するドメイン言語から：名詞はしばしばクラスを示唆し、動詞はしばしば関係や振る舞いを示唆します。

2. ルールを明確化する具体的な質問を用いて：注文は顧客なしで存在できるか？行がゼロであってもよいか？支払いは再試行できるか？

3. モデリングレベルを選択する概念的な図から技術的なデータベースの決定を除外する。

4. 属性と識別子を追加するモデルの説明に役立つ場合のみ追加する。

5. 多重度を設定するビジネスルールから導き出し、すべての関係の両端を確認する。

6. エッジケースを見直す：削除、履歴レコード、オプションフィールド、繰り返し試行、および値の変更。

7. 描画して見直すドメインの専門家と実装者と共に図を描画して見直す。これは承認するための単なる図ではなく、検証するためのモデルとして扱う。

7. VPasCode と Visual Paradigm を使用する

VPasCodeはブラウザベースのPlantUML サポートを備えたテキストから図へのエディタでありリアルタイムプレビューを備えています。機能説明には、図コードの AI による生成と修正、および構文支援も含まれています。実用的なワークフローは以下の通りです。

1. VPasCode を開き、PlantUML を選択または入力する。

2. 上記の例を貼り付け、描画された図を検証する。

3. PlantUML ソースを反復して改良し、テキストをバージョン管理可能な成果物として保持する。

4. ワークスペースに AI アシスタントが利用可能な場合は、それを使用して初稿を作成または修正する。

5. 生成されたすべてのクラス、関係、多重度、およびビジネスルールを自分で検証する。

Visual Paradigm の AI 支援図ツールは、自然言語の説明から編集可能な図を生成できます。公開されたワークフローでは、プロンプトからクラス図を生成し、その後その要素と関係を整備する方法が説明されています。AI の出力はドラフトとして扱ってください。誤った所有権の推論、制約の欠落、または正当化されていないクラスが含まれる可能性があります。モデルの正確性は、依然として要件との照合によって検証される必要があります。

例えば、AI アシスタントに以下のようにプロンプトを入力します。

オンラインショップのための論理的な UML クラス図を作成してください。顧客が注文を行います。各注文には 1 つ以上の注文行が含まれます。各注文行は 1 つの製品を参照し、数量と購入時の単価を格納します。注文には複数の支払い試行が含まれる可能性があります。識別子、多重度、および注文ステータスと支払いステータスの列挙型を含めてください。出力は PlantUML のみとします。

その後、受け入れる前に出力を要件に対して見直してください。より良い結果を得るためには、仮定を明確に指定してください。例えば、注文が行なしのドラフト状態であってもよいか、支払いは返金可能かどうかを明示します。

Visual Paradigm は以下を説明していますVPasCodeとしてPlantUML対応エディタライブレンダリング機能付きのAI支援による生成または変更。ツールと利用可能性は、製品バージョンやワークスペースによって異なる場合があります。

8. 簡潔なレビューチェックリスト

クラス図を共有または実装する前に、以下を確認してください：

• 各クラスは意味のあるドメイン概念を表していますか？

• 識別子と重要な属性は明確ですか？

• 関係のラベルと多重度が両方の端で正しいですか？

• 合成は実際のライフサイクル依存関係を反映していますか？

• 現在の値が変化する可能性がある場所で、歴史的な事実は保持されていますか？

• オプション値とビジネス制約は視覚化されていますか？

• この図は対象読者にとって十分に焦点を絞っていますか？

• 生成されたコンテンツは実際の要件に対して確認されましたか？

最適な図-as-コードワークフローは初期ドラフトにはAI、正確な編集とバージョン履歴にはPlantUML、ドメインの正確性には人間のレビューを使用することです.