UML アクティビティ図は、作業の流れをモデル化しますプロセスにおける実行されるアクション、下される意思決定、並行作業、そして完了への経路を表現します。PlantUML を使えば、そのモデルをテキストとして記述し、それを図としてレンダリングできます。これは、改訂やレビューが容易で、プロジェクトドキュメントと一緒に管理できる図を作成したい場合に有用なアプローチです。PlantUML の現在のアクティビティ構文では、「開始, if, 繰り返し、および「フォーク」などの読みやすいキーワードを使用します。古いアクティビティ構文もまだサポートされていますが、新しい図には新しい構文を推奨します。
1. モデル化する対象
プロセスやアルゴリズムを説明するためにアクティビティ図を使用します。例として：」
-
顧客のチェックアウトワークフロー
-
承認プロセス
-
データインポートパイプライン
-
ユースケースの手順
-
人、チーム、またはシステムコンポーネントにまたがる作業
アクティビティは、「注文を検証する」などの作業の単位です。「制御フローはアクティビティを接続し、その順序を示します。「分岐は代替経路の中から選択し、「並行フローは並行して進められる作業を示します。図は振る舞いを明確にするものであり、実装の詳細をすべて文書化しようとするものではありません。
有用な目安：主な質問が「次に何が起こり、どのような条件下で起こるか？」である場合、アクティビティ図は適しています。
2. PlantUML の基礎
PlantUML の図は「@startuml で始まり、” で終わる@enduml。現在のアクティビティ構文では:
-
startは初期ノードを示します。 -
:Action;はアクションを定義します。 -
if (...) then (...)は条件に基づいて分岐します。 -
endifは条件分岐を閉じます。 -
stopはフローを終了します。 -
repeatおよびrepeat whileは反復をモデル化します。 -
fork,fork again、およびend forkは並列作業をモデル化します。
アクションは順序通りに記述され、暗黙的に接続されます。分岐にラベルを追加し、partitionを使用して、責任や役割に基づいて作業をグループ化できます。
ここに最小限の例を示します:
@startuml
start
:リクエストを受信;
:リクエストを検証;
stop
@enduml
3. 分岐と代替パス
使用ifプロセスが選択を行う場合に使用します。分岐のラベルは条件を単に繰り返すのではなく、条件の結果を伝えるべきです。
@startuml
start
:注文を受信;
:在庫を確認;
if (すべての商品が入荷している？) then (はい)
:商品を予約;
:支払いを要求;
else (いいえ)
:顧客に通知;
stop
endif
:注文を確認;
stop
@enduml
ここで、ifは分岐を導入し、endifで閉じます。はいおよびいいえのラベルにより代替案が明確になります。パスがendifの後に共通のアクションへ続くと、フローに再び合流します。
モデリングのヒント:すべての意味のある結果で何が起こるかを明確にしてください。エラー、タイムアウト、または拒否パスが利害関係者にとって重要である場合は、それを明示的に示すようにしてください。
4. ループとリトライ
アクションまたはアクションのグループが繰り返せる場合にループを使用します。この例では、検証に合格するまで入力を求め続けます:
@startuml
start
:提出されたデータを読み込みます;
repeat
:データを検証します;
if (有効？) then (はい)
:データを保存します;
break
else (いいえ)
:検証エラーを表示します;
:ユーザーにデータの修正を求めます;
endif
repeat while (ユーザーは続行します？) is (はい) not (いいえ)
stop
@enduml
ループの終了条件が曖昧な場合、読み取りが難しくなることがあります。再試行を引き起こす条件と、繰り返しを終了させる条件を明確に述べてください。特に、再試行に制限がある場合やキャンセルできる場合がそうです。
5. 並列作業と同期
使用forkは、独立したアクションが並行して発生する可能性がある場合に使用し、end forkは、パスがプロセスを続行する前に同期する必要がある場合に使用します。
@startuml
start
:注文が確認されました;
fork
:確認メールを送信します;
fork again
:倉庫のピッキングリストを準備します;
fork again
:販売ダッシュボードを更新します;
end fork
:注文を処理中としてマークします;
stop
@enduml
fork は必ずしも別々の人を意味するわけではありません。並行するシステム動作を表すこともできます。アクションが実際に並行して発生する場合のみ使用してください。あるタスクが別のタスクが始まる前に完了する必要がある場合は、代わりにそれらを順次モデル化してください。
6. パーティション付きのスイムレーン
パーティションは、責任のある役割、チーム、またはシステムに基づいてアクションをグループ化します。これにより、プロセス自体を変更せずに引き継ぎを明確にできます。PlantUML は、partition.
@startuml
start
partition Customer {
:注文を提出する;
}
partition "Order Service" {
:注文を検証する;
if (注文は有効か？) then (Yes)
:注文レコードを作成する;
else (No)
:検証エラーを返す;
stop
endif
}
partition Warehouse {
:出荷を準備する;
}
partition "Order Service" {
:確認を送信する;
}
stop
@enduml
実際の責任分担に一致するレーンラベルを選択してください。小さなコンポーネントごとに新しいパーティションを作成するのは避け、レーンが多すぎると図が読みづらくなります。
7. データオブジェクトとノート
重要な入力や出力を示すことで、いくつかのワークフローは恩恵を受けます。PlantUML アクティビティ図はオブジェクトノースtereotypeをサポートしており、ノートを使用することで、すべてのアクションラベルを段落にする必要なく、文脈を追加できます。
@startuml
start
:支払いリクエストを受信する;
:支払いを承認する;
note right
支払いプロバイダーの
承認応答を使用します。
end note
:支払い結果を記録する;
stop
@enduml
主要なアクティビティラベルは短く保ってください。読者が必要とするが、それ自体がフローのステップではないビジネスルール、仮定、または補足はノートに記載してください。
8. 完全な例：オンラインチェックアウト
この大規模な例は、パーティション、意思決定、代替パス、並列作業を組み合わせています。
@startuml
title オンラインチェックアウト
start
partition Customer {
:カートを確認する;
:チェックアウトを提出する;
}
partition "Order Service" {
:カートと住所を検証する;
if (カートと住所は有効か？) then (Yes)
:合計を計算する;
else (No)
:検証エラーを表示する;
stop
endif
}
partition "Payment Service" {
:支払いを承認する;
if (支払いが承認されたか？) then (Approved)
:支払いを捕捉する;
else (Declined)
:支払い失敗を返す;
stop
endif
}
partition "Order Service" {
:注文を作成する;
}
fork
partition "Notification Service" {
:注文確認を送信する;
}
fork again
partition Warehouse {
:注文をピッキング用にキューに入れる;
}
end fork
partition "Order Service" {
:注文確認を表示する;
}
stop
@enduml
上から下へ読んでください：顧客がチェックアウトを提出し、注文サービスがそれを検証し、支払いが承認され、注文が作成されます。その後、確認と倉庫の準備が並行して実行されます。検証または支払いに失敗した場合、フローは関連する失敗パスを通じて終了します。
9. 図-as-code ワークフロー
実用的なワークフローは次の通りです：
図-as-code ワークフロー
実用的なワークフローは次の通りです：
-
プロセスを平易な言葉で記述してください。開始点、終了点、主要なアクション、意思決定、例外、並列タスク、および責任ある役割を特定してください。
-
最初の PlantUML ドラフトを作成してください。スタイリングよりも先にロジックに焦点を当ててください。
-
レンダリングして確認してください。結果が自然に読み取れ、分岐とループが理解しやすいことを確認してください。
-
ステークホルダーとロジックを確認してください。レンダリングは構文のみをチェックし、プロセスが正しいかどうかはチェックしません。
-
ソースを修正し、プロジェクトと一緒に保存してください。テキストベースの図は、他のドキュメントと一緒に差分比較やレビューを行うのが簡単です。
ローカルレンダリングには、PlantUML コマンドラインツールで図ファイルを生成できます。ブラウザベースのエディタは、クイックドラフトやプレビューに便利です。PlantUML もブラウザエディタを提供しており、VPasCode はライブプレビューと PlantUML アクティビティ図サポートを備えたブラウザベースのエディタを提供しています。
-
プロセスを平易な言葉で記述してください。開始点、終了点、主要なアクション、意思決定、例外、並列タスク、および責任ある役割を特定してください。
-
最初の PlantUML ドラフトを作成してください。スタイリングよりも先にロジックに焦点を当ててください。
-
レンダリングして確認してください。結果が自然に読み取れ、分岐とループが理解しやすいことを確認してください。
-
ステークホルダーとロジックを確認してください。レンダリングは構文のみをチェックし、プロセスが正しいかどうかはチェックしません。
-
ソースを修正し、プロジェクトと一緒に保存してください。テキストベースの図は、他のドキュメントと一緒に差分比較やレビューを行うのが簡単です。
ローカルレンダリングには、PlantUML コマンドラインツールで図ファイルを生成できます。ブラウザベースのエディタは、クイックドラフトやプレビューに便利です。PlantUML もブラウザエディタを提供しており、VPasCode はライブプレビューと PlantUML アクティビティ図サポートを備えたブラウザベースのエディタを提供しています。
10. Visual Paradigm VPasCode と AI 支援の活用
VPasCode は、Visual Paradigm のブラウザベースのテキストから図への変換エディタです。その PlantUML サポートにはアクティビティ図が含まれており、エディタはライブレンダリングを提供します。Visual Paradigm はまた、組み込みの自然言語による図生成と、図コードの修正や補正のための AI 支援についても説明しています。
有用な AI 支援ワークフロー：
-
図の種類だけでなく、動作についてもプロンプトを入力してください。例えば：
「オンラインチェックアウト用の PlantUML アクティビティ図を作成してください。カート検証、住所検証、支払い承認、失敗経路、注文作成、並行して実行される確認メール送信と倉庫準備を含めてください。顧客、注文サービス、支払いサービス、通知サービス、倉庫の各パーティションを使用してください。現在の PlantUML アクティビティ構文を使用してください。」 -
生成されたソースを検査してください。次の構文を使用していることを確認してください：
@startuml/@enduml、各分岐が実際の条件を表し、失敗または代替パスが処理されていること。 -
VPasCode でレンダリングしてください。プレビューを使用して、構文エラー、分かりにくいラベル、または過度に複雑なレイアウトを見つけてください。
-
PlantUML を自分で、または特定の AI 編集によって洗練させてください。「支払いタイムアウトパスを追加する」や「注文作成後に倉庫準備を順次処理にする」など、具体的な変更を求めてください。
-
そのプロセスに精通している人と一緒に検証してください。AI は妥当な図の草案を作成できますが、組織の実際のプロセスが正しいことを証明することはできません。
VPasCode の正確なコントロールと機能の利用可否は製品エディションによって異なる場合があります。使用中のエディタで現在のオプションを確認してください。
11. Visual Paradigm モデリングワークフロー
図のソースとプレビューを直接操作したい場合は VPasCode を使用してください。タスクにグラフィカル編集やより広範なモデル作業が必要な場合は、Visual Paradigm のモデリング環境を使用してください。Visual Paradigm のガイダンスでは、図の生成またはインポートを行い、その後ビジュアルエディタで洗練させるワークフローが説明されています。具体的なインポートパスは製品とバージョンによって異なる場合があります。
適切な引き継ぎは以下の通りです：
-
PlantUML で草案を作成し、反復してください。
-
レビューのためにレンダリングされた図とソースを共有してください。
-
ビジュアル編集やその他のモデリング機能が必要な場合は、関連する Visual Paradigm エディタで開くかインポートしてください。
-
チームが選択した真実のソースとして PlantUML ソースを維持バージョンとして保持してください。2 つの場所で矛盾する編集を黙って行わないでください。
12. 一般的なミスと品質チェックリスト
図を共有する前に、以下を確認してください：
-
明確な開始点と意味のある終了点がありますか？
-
各アクションは認識可能な作業の一部を説明していますか？
-
意思決定の結果は明確にラベル付けされていますか？
-
拒否、エラー、タイムアウト、またはキャンセルのパスは、必要な場合に含まれていますか？
-
ループ条件は、繰り返しと終了の動作を明確にしていますか？
-
並列アクションは本当に独立しており、必要な場所で同期が示されていますか？
-
パーティションは有用な所有権の境界を表していますか？
-
読者は長いアクションラベルを読まずにフローを理解できますか？
-
レンダリングされた図は実際のプロセスと一致していますか？
良いアクティビティ図は、最も長いものや最も詳細なものではありません。それは、ワークフロー、意思決定、責任、および重要な例外を明確にする最も小さな図です。
クイック構文リファレンス
| 目的 | PlantUML パターン |
|---|---|
| 開始 | start |
| アクション | :何かを行います; |
| 分岐 | if (条件？) then (はい) ... else (いいえ) ... endif |
| ループ | repeat ... repeat while (条件？) |
| 並列処理 | fork ... fork again ... end fork |
| 責任グループ | partition Role { ... } |
| 終了 | stop |
例は PlantUML の現在のアクティビティ図構文を使用しています。一般的な構文やバージョン固有のレンダリング動作については、PlantUML アクティビティ図リファレンスを参照してください。