de_DEen_USes_ESfa_IRfr_FRid_IDjapl_PLpt_PTru_RUvizh_CNzh_TW

VPasCode ツールを用いた 14 種類の UML ダイアグラムタイプの実践的ガイド

UML ダイアグラムは一般的に「構造的」ダイアグラムと「行動的」ダイアグラムに分類されます。前者はシステムが何で構成されているかを記述し、後者はシステムが何を行うかを記述します。以下の例は、比較と適応を容易にするため、単一のオンラインストアのシナリオを使用しています。ここで参照されている形式仕様は UML 2.5.1 です。

PlantUML は多くの UML 記法を直接描画します。いくつかの特殊なダイアグラムタイプ、特にプロファイル、複合構造、通信、およびインタラクション概要は、専用のダイアグラムレンダラーではなく、実用的な PlantUML の近似表現で記述されることがあります。これらのケースはコメントで識別されます。

構造的ダイアグラム

1. クラス図

システムのクラス、そのデータと操作、および関連、継承、合成などの関係を示します。ドメインモデルやオブジェクト指向設計について議論する際に使用します。

@startuml
class Customer {
  +id: String
  +email: String
  +placeOrder(): Order
}

class Order {
  +number: String
  +status: OrderStatus
  +total(): Money
}

class OrderLine {
  +quantity: int
  +unitPrice: Money
}

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

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

読み解くと:1 人の顧客は多数の注文を行うことができ、1 つの注文には 1 つ以上の行が含まれ、各行は製品を参照します。塗りつぶされたダイヤモンドは合成を示しており、注文がその行を所有していることを意味します。

2. オブジェクト図

ある一時点における具体的なインスタンスとリンクを示します。例示データを示したり、特定のシナリオを用いてクラスモデルを説明する際に有用です。PlantUML ではオブジェクト記法を使用します。

@startuml
object "alice:Customer" as alice {
  id = C104
  email = [email protected]
}

object "order:Order" as order {
  number = O9001
  status = PAID
}

object "line:OrderLine" as line {
  quantity = 2
  unitPrice = 19.99
}

object "mug:Product" as mug {
  sku = MUG-01
  name = Travel mug
}

alice -- order
order *-- line
line --> mug
@enduml

3. コンポーネント図

デプロイ可能または交換可能なソフトウェア部品とその依存関係を示します。アプリケーションアーキテクチャと統合境界を伝達するために使用します。

@startuml
component "Web Store" as web
component "Order Service" as orders
component "Payment Adapter" as payments
database "Order DB" as db
cloud "Payment Provider" as provider

web --> orders : REST
orders --> db : SQL
orders --> payments : authorize
payments --> provider : HTTPS
@enduml

4. 複合構造図

コンポーネントやクラスなどの分類子の内部部品と、それらがポートを介してどのように接続されているかを示します。周囲のシステムアーキテクチャよりも内部の協働が重要である場合に有用です。

PlantUML は、普遍的にサポートされた専用のコンポジット構造構文を提供していません。このクラス図スタイルのスケッチは、部品と接続を伝達します:

@startuml
allowmixing
skinparam componentStyle rectangle

class Car {
}

package "Car" {
  component "engine : Engine" as engine {
    portout p1
  }

  component "transmission : Transmission" as trans {
    portin p2
    portout p3
  }

  component "wheel : Wheel [4]" as wheels {
    portin p4
  }

  p1 -- p2 : drives
  p3 -- p4 : power
}

@enduml

これは構造的スケッチとして扱ってください。正式な UML ポートやコネクタのセマンティクスは示されていません。

5. デプロイメント図

ソフトウェアアーティファクトやサービスをハードウェアノードおよび実行環境にマッピングします。ソフトウェアがどこで実行され、ランタイムノードがどのように通信するかを説明するために使用します。

@startuml
node "Customer device" as client {
  artifact "Browser"
}

node "Cloud" {
  node "Application host" as appHost {
    artifact "Store API"
  }
  database "Order database" as db
}

cloud "External payment provider" as pay

client --> appHost : HTTPS
appHost --> db : SQL
appHost --> pay : HTTPS
@enduml

6. パッケージ図

モデル要素を名前空間やレイヤーにグループ化し、それらのグループ間の依存関係を示します。コードの組織化とアーキテクチャの方向性を説明するために使用します。

@startuml
package "store.web" {
  class CheckoutController
}

package "store.application" {
  class PlaceOrder
}

package "store.domain" {
  class Order
  class Product
}

package "store.persistence" {
  class OrderRepository
}

CheckoutController ..> PlaceOrder
PlaceOrder ..> Order
PlaceOrder ..> OrderRepository
@enduml

7. プロファイル図

ステレオタイプ、タグ付き値、および制約を使用して、UML へのドメイン固有の拡張を定義します。プロジェクトが標準的な UML を超えた一貫したモデリング語彙を必要とする場合に使用します。

PlantUML はプロファイルの概念を UML スタイルのスケッチとして表示できますが、これは専用のプロファイル図レンダラーではありません。

@startuml
class "«profile» StoreProfile" as Profile
class "«stereotype» «Service»" as Service
class "«stereotype» «Repository»" as Repository
class "«metaclass» Component" as Component

Profile ..> Service : defines
Profile ..> Repository : defines
Service ..> Component : extends
Repository ..> Component : extends

note right of Service
  tagged value:
  owner: String
end note
@enduml

行動図

8. ユースケース図

外部アクターと、それらが相互作用するシステム目標を示します。スコープを確立し、高レベルで機能要件を捉えるために使用します。

@startuml
左から右の方向
アクター Customer
アクター "Payment Provider" を Provider とする

矩形 "Online Store" {
  ユースケース "Browse products" を Browse とする
  ユースケース "Place order" を Place とする
  ユースケース "Pay for order" を Pay とする
  ユースケース "Track order" を Track とする
}

Customer --> Browse
Customer --> Place
Customer --> Track
Provider --> Pay
Place ..> Pay : <<include>>
@enduml

9. アクティビティ図

ワークフロー(アクション、意思決定、並行パス、引き継ぎ)をモデル化します。ビジネスプロセス、運用手順、またはアルゴリズムの制御フローに使用してください。

@startuml
開始
:アイテムを選択;
:配送詳細を入力;
:合計を計算;

if (アイテムは利用可能?) then (はい)
  :支払いを承認;
  if (支払い承認?) then (はい)
    :注文を作成;
    :確認を送信;
  else (いいえ)
    :支払いエラーを表示;
  endif
else (いいえ)
  :利用不可のアイテムを表示;
endif

終了
@enduml

10. 状態マシン図

エンティティが取りうる状態と、遷移を引き起こすイベントまたは条件を記述します。オブジェクトの動作が現在の状態に依存する場合に使用してください。

@startuml
[*] --> 下書き
下書き --> 支払い保留中 : 送信
支払い保留中 --> 支払い済み : 支払い承認
支払い保留中 --> キャンセル : 支払い拒否
支払い保留中 --> キャンセル : カスタマーがキャンセル
支払い済み --> 発送済み : 発送
発送済み --> 配達完了 : 配達確認
キャンセル --> [*]
配達完了 --> [*]
@enduml

11. シーケンス図

参加者間で交換されるメッセージを時間順に示します。シナリオ、API 呼び出しフロー、またはサービス間の相互作用を記述するために使用してください。

@startuml
アクター Customer
参加者 "Web Store" を Web とする
参加者 "Order Service" を Orders とする
参加者 "Payment Service" を Payments とする

Customer -> Web : チェックアウトを送信
Web -> Orders : 注文を作成
Orders -> Payments : 支払いを承認
Payments --> Orders : 承認
Orders --> Web : 注文確認
Web --> Customer : 確認を表示
@enduml

12. 通信図

どのオブジェクトが協力し、それらの間のリンクを強調します。メッセージ番号は相互作用の順序を示します。タイムラインよりも協力する参加者のネットワークが重要である場合に使用してください。

PlantUML の標準 UML セットには、専用の通信図レンダラーはありません。このオブジェクトリンクのスケッチでは、メッセージにシーケンス番号を付記します:

@startuml
オブジェクト Customer
オブジェクト WebStore
オブジェクト OrderService
オブジェクト PaymentService

Customer --> WebStore : 1: checkout()
WebStore --> OrderService : 1.1: createOrder()
OrderService --> PaymentService : 1.2: authorize()
PaymentService --> OrderService : 1.3: approved
OrderService --> WebStore : 1.4: confirmation
@enduml

13. 相互作用概要図

相互作用の高レベルな制御フローのビューを提供し、アクティビティスタイルのフローと相互作用シナリオへの参照を組み合わせます。複数のシーケンスレベルのシナリオがより大きなプロセスにどのように組み込まれるかを示すために使用してください。

この PlantUML の例では、アクティビティ図を概要として使用し、参照される相互作用の代わりにシナリオ名を使用しています:

@startuml
skinparam conditionStyle InsideDiamond

title 相互作用概要図:注文処理システム

start

:顧客が注文します;

if (在庫あり?) then (はい)
  
  partition "sd 決済シーケンス" {
    :支払い承認;
    :在庫引き落とし;
  }
  
else (いいえ)
  
  partition "sd 後発注プロセス" {
    :顧客に通知;
    :サプライヤーへの要求生成;
  }
  
endif

fork
  partition "sd 出荷シーケンス" {
    :注文梱包;
    :住所へ出荷;
  }
fork again
  partition "sd 請求シーケンス" {
    :請求書生成;
    :領収書メール送信;
  }
end fork

:注文を完了;

stop
@enduml

各シナリオ内の詳細なメッセージ交換については、別のシーケンス図を作成してください。

14. タイミング図

時間軸に対する状態または値の変化を示します。時間依存の動作、プロトコル、ハードウェア間の相互作用、または期間や期限に関連する要件に使用してください。

@startuml
robust "Order" as Order
concise "Payment" as Payment

@0
Order is Draft
Payment is Idle

@5
Order is Pending
Payment is Processing

@10
Payment is Approved

@12
Order is Confirmed
@enduml

図の選択

図で答えなければならない質問から始めてください:

  • システムには何があるか?クラス、オブジェクト、コンポーネント、複合構造、パッケージ、プロファイル、またはデプロイメント。

  • システムは何を行うか?ユースケース、アクティビティ、または状態機械。

  • 参加者はどのように協力するか?シーケンス、通信、相互作用概要、またはタイミング。

各図は一つの目的に焦点を当て、図全体で一貫した名前を使用し、対象者とその場で意思決定に必要な詳細のみを含めてください。PlantUML のスニペットは出発点です:レンダラーがサポートする構文、特に特殊な図タイプについて確認してください。