ビジネスプロセスからユースケースを特定する
BPMNは、ビジネスプロセスを支援するソフトウェアの要件を特定するためにますます利用されています。ソフトウェア要件は、しばしばビジネスプロセスと整合性を欠いていることが見られます。したがって、ビジネスプロセスモデルに基づいた要件の抽出により、ビジネスプロセスとソフトウェアモデルの整合性が確保され、ユーザーが期待するものを実現する可能性が高まります。
開発チームは、ビジネスプロセスモデルを用いてビジネスの業務フローを視覚的に文書化し、システムが達成すべき望ましい機能をモデル化するために、ユースケースをこれらのビジネスプロセスに関連付けることができます。このチュートリアルでは、モデルトランジタ機能を活用して、ユースケースとビジネスプロセスの間のトレーサビリティを確立する方法を詳しく説明します。
BPMNとBPDとは何ですか?
BPMNは、ビジネスアナリストにビジネスプロセスをモデル化するためのグラフィカルな記法のセットを提供します。当初はビジネスプロセス管理イニシアチブ(BPMI)によって開発され、現在はオブジェクト管理グループ(OMG)によって維持されています。BPMNを開発する動機の一つは、異なる役割、異なる国、あるいは異なる母国語を持つ人々が、障壁なく同じビジネスプロセスを理解できる共通のグラフィカル言語を提供することです。
BPDはビジネスプロセス図の略称であり、BPMNを用いてビジネスプロセスをモデル化する場所です。フローチャートのような図で、プロセスの流れ、関与する参加者、参加者間のメッセージ交換を示します。ビジネスアナリストは、異なる参加者がどのように協働してビジネス目標を達成するかをモデル化するためにBPDを描きます。最終ユーザーとの整合性を確認した後、システムアナリストはシステムの計画を開始できます。
以下の図は、組織の登録プロセスの簡単なBPDです。通常見られるモデル化記法の多くをカバーしています。見てみましょう。

| 記法 | 説明 |
|---|---|
![]() |
Pool – プロセス内の参加者を表します。BPMNでは、プールとレーンの両方が参加者を表すために使用されます。レーンは親プールのサブパーティションをモデル化するためにプール内に含まれます。 |
![]() |
開始イベント – プロセスの開始を表します。トリガーを定義することで、プロセスがどのような状況で起動されるかを読者に伝えられます。たとえば、メールが受信されたとき/月曜日の朝/エラーが発生したときなど。 |
![]() |
タスク – 指定された参加者(プール/レーンでモデル化)が実行する可能性のある原子的な活動です。タスクやその他のフローオブジェクトがつながって、完全なビジネスワークフローを形成します。 |
![]() |
終了イベント – プロセスの終了を表します。プロセス終了時に何が起こるかを読者に伝えるために、結果を定義できます。たとえば、信号を発信する/エラーを発生させるなど。 |
このチュートリアルでは、BPDやビジネスプロセスモデリングに重点を置きません。BPMN、BPD、またはビジネスプロセスモデリングについてさらに学びたい場合は、『BPMN入門I~IV』のチュートリアルをお読みください。BPMN Part I to IV.
ユースケース図とは何ですか?
ユースケースモデリングとは、UMLのユースケース図を用いて高レベルのユーザー要件を捉える技術を指します。ユースケースモデルは、ソフトウェアやシステム設計者向けに設計されており、ビジネスパーソン向けではありません。
ユースケース図には主に3つの要素があります。
| 記法 | 説明 |
|---|---|
![]() |
ユースケース – 各ユースケースは、システムのユーザーが達成したい目標を表しており、ユーザーがシステムを使って達成したい目的です。ユースケースは、ユーザーが何をしたいのかを示すものであり、開発者が何を開発する必要があるかを示すものではないことに注意してください。ただし、場合によっては両者が一致することもあります。ユースケースに関与する機能を文書化またはモデル化したい場合、イベントの流れツールを使用するか、ユースケースを以下のように詳細化できます。シーケンス図/アクティビティ図ただ、ユースケースモデリングの目的は、ユーザーが何を達成したいのかをモデル化することであることを忘れないでください。 |
![]() |
アクター – システムのユーザー。ここでの「ユーザー」という言葉は人間に限定されるものではありません。私たちのシステムとやり取りして特定のビジネス目的を達成するシステムも含まれます。 |
![]() |
通信リンク/関連性 – アクターとユースケースの間に接続し、アクターによるシステムへのアクセスを示します。各通信リンクは、アクターとシステム間のトランザクションの順序を示します。 |
BPDからユースケース図への移行
BPDとユースケース図は必ずしも互いに依存する必要はありませんが、補完的な関係にある場合があります。通常、私たちは特定のビジネスプロセスのワークフローを自動化または最適化するためにソフトウェアを開発します。BPDを用いることで、参加者がどのように協働しているか、誰が何を担当しているかを理解でき、ユーザーがシステムに何の機能を求めるかを特定できます。ユーザーが求めているシステム機能(ワークフローまたはビジネスプロセス)は、ユースケースとしてモデル化し、その後チームが開発できます。その結果、BPDは開発中のシステムのユースケースを特定するのに役立つと言えます。
Visual Paradigmは、モデルトランジタ機能を通じて、2つのモデル間のトレーサビリティリンクを確立することで、ビジネスプロセスの実施からユースケースモデリング(ビジネス要件からアプリケーション要件)までをサポートする視覚的モデリングツールです。トレーサビリティが必要な理由は以下の通りです:
- ユースケースが関与するプロセスフローの一部を検討することで、システムが現実の使用状況に適合しているか確認できます。
- ユースケースが移行したプロセスの一部をトレースすることで、「なぜこの(システム)機能が必要なのか?」という質問に答えることができます。
- BPDからユースケース図にトレースすることで、「特定の操作はすでに実装されたか?」という質問に答えることができます。
BPDとユースケース図の比較
BPDをユースケース図に移行する際、lane/poolからアクターを生成し、タスク/サブプロセスからユースケースを生成できます。以下の表は、モデル移行の観点から、pool、lane、アクター、タスク、サブプロセス、ユースケースの特徴を示しています。
| 元 | 先 | 説明 |
|---|---|---|
![]() ![]() |
![]() |
Pool/Laneからアクターへ
BPDでは、poolはビジネスプロセスの参加者を表し、laneはpoolのサブパーティションです。プロセスに関連する活動を実行する者はすべて参加者とみなされます。ユースケース図では、アクターはシステムのユーザーを表します。システムのユーザーでない人物や役割は、アクターとして扱わないように注意してください。 |
![]() ![]() |
![]() |
タスク/サブプロセスからユースケースへ
BPDでは、タスク/サブプロセス(アクティビティ)とは、ビジネスプロセスを完了するために参加者が実行する可能性のあるあらゆる行動を指します。ユースケース図では、ユースケースはユーザーがシステムを使って達成したい目標を表します。アクティビティがシステム機能に関連する必要はないこと、また1つのユースケースが複数のアクティビティを満たす可能性があることを覚えておいてください。 |
一部の人々は、ユースケース図がBPDに似ているように思いますが、記法や目的において大きく異なります。BPMNはビジネスパーソン向けに設計されているのに対し、ユースケース図はシステムアナリストやシステム開発者向けであることを忘れないでください。両者は異なる目的を持ち、ビジネスを異なる視点から読み解きます。そのため、前節では「BPDはユースケースを特定するのに役立つ」と述べました。BPDはユースケースを特定する際のヒントを与えるだけです。BPD内のすべてのタスクがユースケースに等しいというルールはありません。しかし、ターゲットシステムによる機能の自動化のために、ユースケースを使ってビジネスプロセスを詳細化することは可能です。
ケーススタディでは、BPDをユースケース図に移行する際、どのような点に注意すべきかについていくつかのヒントを提供します。これにより、両者の違いが理解できるでしょう。
事例研究:トゥルーオーシャ・ディスティルドウォーター会社
トゥルーオーシャ・ディスティルドウォーター会社は、都市内の若手のディスティルドウォーター販売業者です。同社は、ビジネス用および家庭用のディスティルドウォーターを販売しています。以下は、同社の水配達プロセスのテキスト記述です。
| ディスティルドウォーターを注文するには、顧客は注文ホットラインに電話するか、メールを送信します。現在、注文の90%が電話によるものであり、残り10%がメールによるものです。注文を受けたカスタマーサービスアシスタントは、顧客が既存の顧客か新規顧客かを確認します。初めて注文する顧客の場合は、カスタマーサービスアシスタントが顧客アカウントを作成した後、水の配達へと進みます。
ディスティルドウォーターの配達は毎週水曜日に1回実施されます。したがって、毎週水曜日の朝、カスタマーサービスアシスタントは注文を物流部門に転送して配達を依頼します。物流部門のマネージャーが注文を受けた後、各注文に従業員を割り当て、スケジュールを印刷・掲示して配達を手配します。従業員は電話を受け、顧客に水を配達します。 |
記述に基づいてビジネスプロセスモデルが作成されました。今、あなたには全体のプロセスを最適化するコンピュータシステムを開発するよう依頼されています。まず行うべきことは、ユースケースモデルを開発することです。BPDの助けを借りて、ユースケース図を開発してみてください。
- ダウンロード ディスティルドウォーター配達.vpp。このチュートリアルの下部にもこのファイルがあります。
- ダウンロードした .vpp ファイルを Visual Paradigm で開きます。プロジェクトを開くには、「プロジェクト > 開く」を選択してください。プロジェクト > 開くアプリケーションツールバーから。
- BPD を開く 蒸留水注文プロセス。プロセスフローを慎重に検討してください。

- プロセスは顧客が注文を提出したときに開始されます。ここでは「注文を提出」というユースケースを想定できます。このユースケースは、顧客がカスタマーサービスアシスタントの支援なしに注文を提出できるインターフェースを提供することでプロセスを自動化し、顧客の身元を確認し、顧客が存在しない場合はアカウントを作成します。右クリックして「注文を提出」を選び、「関連要素 > 新しいユースケースへ移行…」を選択してください。関連要素 > 新しいユースケースへ移行…ポップアップメニューから。

- これにより、モデル要素の移行ウィンドウが表示され、ユースケースとアクターを配置するモデルを選択し、名前を変更できます。この場合、ユースケースとアクターの名前は問題ありません。変更せずにそのままにしてください。クリックしてOK.

これにより、UeXceler に新しいユースケース図が作成されます。

- BPD に戻ります。
- 以下のタスクについて検討しましょう顧客アカウントの作成。ビジネスプロセスでは、カスタマーサービスアシスタントはすべての新規顧客に対してアカウントを作成する必要があります。新しいシステムでは、この作業は「注文を提出」ユースケースの一部として行うか、カスタマーサービスアシスタントが手動でトリガーする別個のユースケースとして行うことができます。注文を提出ユースケースとして行うか、カスタマーサービスアシスタントが手動でトリガーする別個のユースケースとして行うことができます。現実の状況では、誤ったユースケースモデルはユーザーの期待に合わない機能の開発を引き起こすため、このような疑問はステークホルダーと確認する必要があります。この例では、ユーザーが「顧客アカウントの作成」タスクをカスタマーサービスアシスタントが実行することを希望していると仮定します。このタスクからユースケースを作成しましょう。顧客アカウントの作成タスクをカスタマーサービスアシスタントが実行することにします。このタスクからユースケースを作成しましょう。「顧客アカウントの作成」を右クリックして、「関連要素 > 新しいユースケースへ移行…」を選択してください。顧客アカウントの作成を右クリックして、「関連要素 > 新しいユースケースへ移行…」を選択してください。関連要素 > 新しいユースケースへ移行…ポップアップメニューから。

- 再び、ユースケースとアクターの名前は問題ありません。モデル要素の移行ウィンドウ内のすべての内容を変更せずにそのままにしてください。クリックしてOK. ユースケース図は新しいユースケースとアクターで更新されました。確認しましょう。

- BPDに戻ります。サブプロセスに進みましょう。配達の手配. 物流部門のマネージャーは、システムを使ってスケジューリングを行い、従業員に水の配達を通知できます。したがって、これはシステムのユースケースでもあります。サブプロセスを右クリックして配達の手配 そして関連要素 > 新しいユースケースへの移行… をポップアップメニューから選択します。
- 「移行モデル要素」ウィンドウでアクター「マネージャー」を確認してください。もしアクターの名前を「マネージャー」のままにすると、ユースケースモデル上で曖昧になります。会社には多くの部署があり、それぞれに異なるマネージャーがいる可能性があるためです。したがって、アクターの名前を「物流部門マネージャー.

- 」に変更してください。OK。ユースケース図が更新されました。

- BPDに戻ります。最終タスク「水の配達」は人間だけが行える作業であり、システムとのやり取りとは関係ありません。したがって、これに対してユースケースを作成する必要はありません。
- 地域マネージャーが、注文の統計を示すレポートを生成できる新しい機能をシステムがサポートするようにしたいと仮定します。この機能は、マーケティング戦略の見直しと改善に役立ちます。この機能はビジネスプロセスモデルではモデル化されていませんが、ユースケース図に直接描画できます。ユースケース図を開いてください。アクター「地域マネージャー」を描画してください。これからユースケース「統計レポートの生成」を関連付けて作成してください。

- クライアントが顧客に請求書の閲覧および注文のキャンセルを許可したいと仮定します。また、物流部門マネージャーが物流レポートの印刷を許可したいとします。それぞれに対応するユースケースを描画してください。

- 図を整理しましょう。

- 遷移関係により、ユースケースモデルからビジネスプロセスモデル(およびその逆)を追跡できます。試してみましょう。マウスを「注文するユースケース。

- クリックしてくださいモデルトランジタ図形の右下隅にあるリソース。選択してください転送元 > 蒸留水注文プロセス <.注文するポップアップメニューから。

これにより、タスクが選択されたBPDが開きます注文する選択済み。













