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 のスニペットは出発点です:レンダラーがサポートする構文、特に特殊な図タイプについて確認してください。












