PlantUMLとVPasCodeによるUMLユースケース図のコード化

UMLユースケース図は、システムが提供する機能と、それと相互作用する人または対象を示します。図をコードとして扱うワークフローでは、図のソースはプレーンテキストです：テキストを編集し、図をレンダリングし、ソースをプロジェクトドキュメントと一緒に保管します。

PlantUMLはユースケース図をサポートしています。Visual ParadigmのVPasCodeエディタは、PlantUMLエディタとプレビュー機能に加え、AI支援による図の生成および編集機能を提供します。

1. ユースケース図が伝えること

ユースケース図は、システムの範囲とユーザーの目標に焦点を当てます、ワークフローの段階的なメカニズムではありません。図には通常、次の要素が含まれます：

• システム境界：モデル化されているシステムの名前を付けた矩形。

• アクター：システム外でそれと相互作用する役割。アクターは人、組織、デバイス、または外部システムになり得ます。

• ユースケース：システムが提供する機能または目標。通常は楕円で表され、動詞句（例：「注文を置く」）で名前が付けられます。

• 関連：アクターがユースケースに参加していることを示す線。

• ユースケースの関係：Include（包含）、extend（拡張）、および一般化。

アクターは特定の個人ではなく役割を表します。モデル化されているシステムと相互作用する場合、外部の決済サービスもアクターになり得ます。

ユースケース図は、システムの範囲を明確にすること、ステークホルダーとの要件に関する議論、外部依存関係の特定、開発およびテストのための共通の概要を提供するために役立ちます。事前条件、主要な手順、代替フロー、結果などの詳細が必要な場合は、それらを書き起こしたユースケース記述と併用してください。

2. 関係の概要

• アクターとユースケースの関連：相互作用を示す単なる線。

• <<include>>:包含するユースケースは、常に包含される振る舞いを使用します。破線の矢印は包含するユースケースから包含されるユースケースへ向かいます。例えば、注文を行う際には常に支払い承認が含まれる場合があります。

• <<extend>>:拡張するユースケースは、条件付きで基本ユースケースに振る舞いを追加します。破線の矢印は拡張ユースケースから基本ユースケースへ例えば、プロモーションの適用は注文の処理を拡張する場合があります。

• 一般化: 特定のアクターまたはユースケースは、より一般的なものを継承します。実線で描かれた中空の三角形は、一般的な要素を指します.

有用な区別: include は必須の振る舞いを意味し、extend は条件付きで追加される振る舞いを意味します。

3. PlantUML の基本

PlantUML の図は@startumlで始まり、@endumlで終わります。アクターはactorで宣言し、ユースケースはusecaseで宣言し、システム境界はrectangleで宣言します。エイリアスを使用すると、関係内での要素の参照が容易になります。

@startuml
left to right direction

actor Customer

rectangle "Online Store" {
  usecase "Browse products" as Browse
  usecase "Place order" as Place
}

Customer --> Browse
Customer --> Place
@enduml

左から右の方向は、PlantUML に図を横方向に配置するよう指示します。図が変更されると、PlantUML は正確なレイアウトを調整する場合があります。

4. 例：基本的なオンラインストア

@startuml
左から右の方向

アクター Customer
アクター Administrator を Admin とする

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

Customer --> Browse
Customer --> Place
Customer --> Track
Admin --> Manage
@enduml

顧客は商品の閲覧、注文、配送追跡を行います。管理者はカタログを管理します。この図は、注文処理の内部手順をあえて省略しています。

5. 例：include と extend

注文には常に支払い承認が必要であるが、プロモーションの適用は任意かつ条件付きであると仮定します。

@startuml
左から右の方向

アクター Customer

矩形 "Online Store" {
  ユースケース "Place order" を Place とする
  ユースケース "Authorize payment" を Payment とする
  ユースケース "Apply promotion" を Promotion とする
}

Customer --> Place

Place ..> Payment : <<include>>
Promotion ..> Place : <<extend>>
@enduml

このPlace ..> Payment矢印は、「注文」に必要な支払い処理を含意することを意味します。このPromotion ..> Place矢印は、条件が満たされた場合に「プロモーションの適用」が「注文」を拡張することを意味します。

条件（例：「顧客が有効なプロモーションコードを入力する」）をユースケースの説明または注釈に記載してください。

6. 例：アクターの一般化と外部システム

特殊化されたアクターは、より一般的なアクターから相互作用を継承します。外部サービスもシステムと相互作用する場合はアクターとなり得ます。

@startuml
左から右の方向

アクター "User" を User とする
アクター "Registered customer" を Customer とする
アクター "Payment gateway" を Gateway とする

Customer --|> User

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

User --> Browse
Customer --> Place
Place ..> Pay : <<include>>
Gateway --> Pay
@enduml

「登録顧客」は「ユーザー」を特殊化し、一般的なユーザーインタラクションを継承します。決済ゲートウェイはオンラインストアの境界外にありますが、決済ユースケースに参加します。

7. 例：ユースケースの一般化

一般化は、より広範なユースケースの特殊化されたバージョンを表すことができます。空の三角形は、一般的なユースケースの方向を指します。

@startuml
left to right direction

actor Customer

rectangle "Payment System" {
  usecase "Make payment" as Payment
  usecase "Pay by card" as Card
  usecase "Pay by bank transfer" as Transfer
}

Customer --> Card
Customer --> Transfer

Card --|> Payment
Transfer --|> Payment
@enduml

特殊化されたユースケースが共通の目標を共有しているが、意味のある違いがある場合にこれを使用してください。バリエーションが単なる条件付きステップである場合、<<extend>>関係または書面によるユースケースの説明の方が明確である場合があります。

8. VPasCode での作業

実践的なワークフロー：

1. スコープを定義する。システムの境界、アクターの役割、および各役割が達成したい目標を特定する。

2. ドラフトを作成する。PlantUML を直接記述するか、AI アシスタントにユースケース図の生成を依頼する。

3. コードとプレビューを確認する。アクターがシステムの境界外にあり、ユースケースがその内部にあり、矢印が正しい方向を指していることを確認する。

4. モデルを洗練させる。曖昧な名称を置き換え、実装の詳細を削除し、実際の要件を反映している場合のみ関係を追加する。

5. ターゲットを絞った AI による編集を依頼する。例：「外部の決済ゲートウェイアクターを追加し、include 関係を使用して必要な決済インタラクションを示してください。それ以外は変更しないでください。」

6. 関係者と検証する。図がシステムの実際のスコープとユーザーの目標を反映しているか確認する。

7. ソースを保存する。 を保持してください.pumlプロジェクトのドキュメントまたはバージョン管理システムにテキストを保存してください。ドキュメントやプレゼンテーションが必要な場合にのみ画像をエクスポートしてください。

AI支援のためのプロンプト例

オンラインストア用のPlantUMLでUMLユースケース図を作成してください。システム境界、顧客と管理者というアクター、および「商品閲覧」「注文の作成」「配送追跡」「カタログ管理」という目標を含めてください。支払い承認は「注文の作成」によって必須として含まれる動作として示してください。プロモーションの適用は「注文の作成」の条件付き拡張として示してください。有効なPlantUMLソースのみを返してください。

AIによって生成されたコードは下書きとして扱ってください。使用する前に、アクター、境界、関係、およびビジネス上の前提条件を確認してください。

9. 一般的な落とし穴

• 内部コンポーネントをアクターとしてモデル化する:アクターは、対象と相互作用する外部の役割またはシステムであるべきです。

• ユースケースを実装タスクとして命名する:“配送追跡”を”追跡APIを呼び出す”よりも優先してください。

• の<<include>>をオプションの動作に使用すること:Includeは、基本ユースケースが要求する動作を表します。

• 関係の矢印の向きを逆にする:Includeは、含まれるユースケースを指します。extendは、基本ユースケースを指します。

• 1つの図に詳細を詰め込みすぎる:スコープには高レベルの図を使用し、詳細なシナリオには別の図またはテキストを使用してください。

• レンダリングが成功すればモデルが正しいと仮定する:PlantUMLは、要件を誤って表現しているにもかかわらず図をレンダリングできる場合があります。

10. 確認チェックリスト

図を共有する前に、次のことを確認してください:

• システム境界が明確であること。

• すべてのアクターが外部にあり、役割を表していること。

• ユースケースの名前が意味のある目標を説明していること。

• アクターの関連性が実際の相互作用を反映していること。

• Include関係は必須であり、extend関係は条件付きまたはそれ以外で正当化されていること。

• 一般化の矢印が、一般的なアクターまたはユースケースを指していること。

• 図が意図したサイズで読みやすくなっていること。

• AIによって生成された仮定は、要件に精通した関係者とレビュー済みです。