UMLクラス図の習得:PlantUMLを活用したシステム設計における実践的ケーススタディ
はじめに
今日の複雑なソフトウェア開発環境において、明確なコミュニケーションと正確なシステムモデリングはプロジェクトの成功にとって不可欠です。ソフトウェアアーキテクトのツールキットの中でも特に強力なツールの一つが、UMLクラス図——抽象的な要件と具体的な実装の間をつなぐ視覚的言語です。
このケーススタディでは、クラス図がオブジェクト指向設計の基盤として果たす役割を検証し、チームがシステムの静的構造をモデル化し、エンティティ間の関係を定義し、開発のための明確な契約を確立できるようにする方法を示します。実際のeコマース注文管理システムを例に、概念的、仕様的、実装的という3つの開発視点から、クラス図を段階的に精緻化する方法を示します。同時に、PlantUMLを活用して、実行可能でバージョン管理可能なドキュメントを作成します。
ビジネスアナリストとしてドメイン概念をモデル化している場合、開発者がAPIを設計している場合、あるいはチームリーダーとしてアーキテクチャの整合性を確保している場合でも、このガイドは、明確さを高め、曖昧さを減らし、開発を加速するクラス図の作成に役立つ実践的な知見を提供します。
クラス図の理解:基本概念のまとめ
(基礎知識の要約)
UMLにおけるクラス図は、静的構造図であり、以下の内容を可視化します:
-
クラス:属性(状態)と操作(振る舞い)を持つオブジェクトを定義する設計図
-
関係:継承、関連、集約、合成、依存
-
制約:可視性(
+,-,#,~)、多重度(1,0..*,1..5)、および航行可能性
主要な記法要素

@startuml
class Order {
-orderId: String
-orderDate: Date
+calculateTotal(): Double
+addItem(item: Product, qty: int): void
}
@enduml
関係タイプのクイックリファレンス
| 種類 | 記号 | 意味 | 例 |
|---|---|---|---|
| 継承 | `– | >` | 「は-a」 |
| 関連 | -- |
構造的リンク | Order -- Customer |
| 集約 | o-- |
「は-a」(弱い) | Warehouse o-- Product |
| 合成 | *-- |
「所有-a」(強い) | Order *-- OrderItem |
| 依存関係 | ..> |
「uses」(一時的) | PaymentService ..> Logger |
事例研究:EC注文管理システム
ビジネス要件
オンライン小売業者がシステムを必要とする理由:
-
顧客、製品、注文を管理する
-
数量と価格を備えた注文項目をサポートする
-
複数の決済方法を処理する
-
ライフサイクルを通じて注文状態を追跡する
-
製品がカテゴリに属することを許可する
-
ゲストチェックアウトをサポートする(顧客の関連付けは任意)
フェーズ1:概念モデル(ドメイン視点)
言語に依存せず、現実世界の概念に注目する

@startuml
title 概念モデル:ECドメイン
class Customer {
名前
メールアドレス
配送先住所
}
class Product {
名前
説明
基本価格
}
class Category {
名前
説明
}
class Order {
注文番号
注文日
状態
合計金額
}
class OrderItem {
数量
単価
小計
}
class Payment {
決済方法
取引ID
金額
時刻
}
' 関係
Customer "1" -- "0..*" Order : 作成 >
Order "1" *-- "1..*" OrderItem : 含む >
Product "1" -- "0..*" OrderItem : 出現する >
Product "0..*" -- "1" Category : 属する >
Order "1" -- "1..*" Payment : 支払われる >
note right of Order
注文は顧客の
購入意思と取引を表す
end note
@enduml
重要な設計意思決定:
-
合成(
*--)間の注文と注文項目:注文がなければ項目は存在できない -
間の関連:
製品とカテゴリ: 商品は再分類できます -
多重性
0..*カスタマーオーダー用:ゲストチェックアウトをサポート
フェーズ2:仕様モデル(インターフェース視点)
ソフトウェア契約に注目し、実装の詳細を隠蔽する

@startuml
title 仕様モデル:サービスインターフェース
interface IOrderService {
+createOrder(customerId: String, items: List<OrderItemDTO>): OrderDTO
+getOrder(orderId: String): OrderDTO
+updateOrderStatus(orderId: String, status: OrderStatus): boolean
+calculateOrderTotal(orderId: String): Money
}
interface IPaymentProcessor {
+processPayment(orderId: String, paymentDetails: PaymentDTO): PaymentResult
+refundPayment(transactionId: String, amount: Money): RefundResult
}
interface IInventoryService {
+checkAvailability(productId: String, quantity: int): boolean
+reserveItems(orderId: String, items: List<ReservationItem>): boolean
+releaseReservation(orderId: String): void
}
class OrderDTO {
+orderId: String
+customerId: String
+items: List<OrderItemDTO>
+total: Money
+status: OrderStatus
}
class OrderItemDTO {
+productId: String
+quantity: int
+unitPrice: Money
}
' 依存関係
IOrderService ..> IInventoryService : 使用 >
IOrderService ..> IPaymentProcessor : 協調 >
IOrderService ..> OrderDTO : 戻り値 >
note bottom of IOrderService
オーダー管理の契約を定義する。
実装は異なる(マイクロサービス、モノリスなど)
end note
@enduml
アーキテクチャ上の利点:
-
インターフェースの分離により、独立したデプロイが可能になる
-
DTOは内部モデルとAPI契約を分離する
-
依存関係がマイクロサービスのサービス境界を明確に示す
フェーズ3:実装モデル(コード視点)
Java/Spring Boot実装のための技術固有の詳細

@startuml
title 実装モデル:Java/Spring Bootクラス
package com.ecommerce.order.entity {
class Order {
-@Id orderId: UUID
-@ManyToOne customer: Customer
-@OneToMany(cascade=ALL) items: List<OrderItem>
-orderDate: LocalDateTime
-status: OrderStatus
-totalAmount: BigDecimal
+addItem(product: Product, qty: int): void
+calculateTotal(): BigDecimal
+markAsShipped(): void
}
class OrderItem {
-@Id itemId: UUID
-@ManyToOne order: Order
-@ManyToOne product: Product
-quantity: int
-unitPrice: BigDecimal
+getSubtotal(): BigDecimal
}
enum OrderStatus {
PENDING
CONFIRMED
SHIPPED
DELIVERED
CANCELLED
}
}
package com.ecommerce.payment.service {
class PaymentService {
-@Autowired paymentGateway: PaymentGateway
-@Autowired orderRepository: OrderRepository
+processPayment(orderId: UUID, dto: PaymentRequest): PaymentResponse
-validatePaymentDetails(dto: PaymentRequest): void
-updateOrderPaymentStatus(orderId: UUID, status: PaymentStatus): void
}
interface PaymentGateway {
+charge(amount: BigDecimal, card: CardDetails): TransactionResult
+refund(transactionId: String, amount: BigDecimal): RefundResult
}
}
' 関係
Order "1" *-- "1..*" OrderItem : コンポジション >
Order ..> PaymentService : 依存 >
PaymentService ..> PaymentGateway : 実装経由 >
note right of OrderItem
@Entityアノテーションはデータベーステーブルにマッピングされる。
Cascade=ALLにより、アイテムが注文と共に永続化される。
end note
@enduml
実装のポイント:
-
JPAアノテーション(
@Entity,@ManyToOne)はORMマッピング用 -
依存関係の注入(
@Autowired)は緩い結合のため -
型安全な注文ステータス管理のための列挙型
-
プライベートヘルパーメソッド(
-validatePaymentDetails)はロジックをカプセル化する
高度なパターンとベストプラクティス
1. 可視性とカプセル化の扱い方

@startuml
class BankAccount {
+accountNumber: String
+getBalance(): BigDecimal
-balance: BigDecimal
-transactionHistory: List<Transaction>
#calculateInterest(rate: double): BigDecimal
~internalAudit(): void
}
note right of BankAccount
+ 公開: 外部クライアント用のAPI
- 私有: 内部状態、外部からアクセス不可
# プロテクト: サブクラスの拡張用
~ パッケージ: 同じモジュール内でのみ可視
end note
@enduml
2. 実世界のシナリオにおける多重性

@startuml
class ShoppingCart {
+addItem(product: Product, qty: int): void
+removeItem(productId: String): boolean
}
class Product {
+name: String
+price: BigDecimal
+inStock: boolean
}
' カートは0個以上のアイテムを持つことができる
' 各アイテムは正確に1つの製品を参照する
ShoppingCart "1" *-- "0..*" Product : 含む >
note bottom
多重性のルール:
• 0..* = オプション、複数(最も一般的)
• 1 = 正確に1つ(必須)
• 0..1 = オプション、単一(例:プロフィール画像)
• 1..* = 1つ以上(例:注文アイテム)
end note
@enduml
3. 抽象クラスとインターフェースの違い

@startuml
abstract class Notification {
#recipient: String
#message: String
+abstract send(): boolean
+logDelivery(): void
}
interface EmailNotification {
+subject: String
+send(): boolean
}
interface SMSNotification {
+phoneNumber: String
+send(): boolean
}
Notification <|-- EmailNotification
Notification <|-- SMSNotification
note right of Notification
抽象クラス: 共有状態 + 部分的な実装
インターフェース: 純粋な契約、複数継承のサポート
end note
@enduml
一般的な落とし穴と回避方法
| 落とし穴 | 症状 | 解決策 |
|---|---|---|
| 過剰設計 | クラスが50個以上の図、読みにくい | 概念モデルから始め、境界付きコンテキストごとに複数の図に分割する |
| 集約/構成の混同 | オブジェクトのライフサイクル管理が不明瞭 | 尋ねる:「全体が破棄された場合、部分は生存するか?」もし「いいえ」なら、構成を使用する(*--) |
| ナビゲーション性の無視 | あらゆる場所に双方向の矢印 | コード内で移動が必要な場所にのみナビゲーション性の矢印を追加する |
| 抽象レベルの混在 | 同じ図にDTOとエンティティクラスが混在している | 視点(概念/仕様/実装)ごとに図を分ける |
| バージョン管理の無視 | 図が古くなりがちになる | GitにPlantUMLのテキストファイルを使用する;CI/CDパイプラインで画像を生成する |
ツール推奨:なぜPlantUMLなのか?
上記の事例の場合、PlantUMLが選ばれたのは、以下の理由からである:
✅ テキストベース:図はコードである—バージョン管理可能、差分比較可能、レビュー可能
✅ ポータブル:ローカルまたはクラウドサービスでレンダリング可能;Confluence、GitHub、VS Codeと統合可能
✅ 保守性が高い:ボックスを再描画せずに図の論理を更新可能
✅ 共同作業に適している:デザイナーでない人もシンプルな構文で貢献可能
サンプルワークフロー:
# 1. 図をテキストとして記述
echo '@startumlnclass User { +name: String }n@enduml' > UserDiagram.puml
# 2. PNG/SVGを生成
plantuml -tpng UserDiagram.puml
# 3. .pumlファイルと生成された画像をGitにコミット
git add UserDiagram.puml UserDiagram.png
結論
クラス図は学術的な演習以上のものであり、ソフトウェア開発ライフサイクル全体にわたって整合性を促進し、技術的負債を削減し、オンボーディングを加速する動的なアーティファクトです。私たちのeコマースケーススタディで示したように、クラス図の真の力は、三つの重要な視点を通じて進化するときに顕在化します:
🔹 概念的:ステークホルダーを共有されたドメイン理解の土台に据える
🔹 仕様:モジュールアーキテクチャのための明確なインターフェースを定義する
🔹 実装:開発者を正確で技術に配慮したブループリントで導く
以下を採用することでPlantUML図をコードとして扱う実践にPlantUMLを採用することで、チームはコードと共に設計を繰り返し改善する柔軟性を得ます。これにより、ドキュメントが実装に遅れることなく、常に最新の状態を保つことができます。思い出してください:最も優れたクラス図は、最も詳細な図ではないのです。それは、適切な時期に適切な対象に適切な質問に答える図なのです。
最終的な教訓:シンプルなスタートから始め、ステークホルダーと検証し、段階的に改善し、常に図の要素を実際のビジネス価値に結びつけること。クラス図が納品物ではなく、協働ツールとなるとき、それらは負担から、より良いソフトウェアを生み出す触媒へと変化するのです。














