BPMNを使用する方法とユースケースおよび他の図を一緒に使用する方法
私はこの質問をstackoverflowで質問しましたが、この質問は適切ではないようです。そこで、ここに投稿して議論します。
BPMN（ビジネスプロセスモデリング表記法）は、視覚化によるビジネスプロセスのモデリングに使用されるため、BPMNダイアグラムの表現を通じて、無形のアイデアを物理的に具体的にすることができます。問題は、UMLでBPMNを整理する方法です。
最初に、ユースケースとビジネスプロセス図を整理する2つの方法を考えました。
1 to one/many：ビジネスプロセス図の各ステップ（
stepはBPMNダイアグラムの各ノードを意味します）をマッピングすることにより、 1つまたは複数の使用例。各ユースケースは、関連するいくつかのクラス図/コンポーネント図（入力と出力を持つ1つのコンポーネントにクラスのセットをカプセル化できるため、これを使用する方が好ましい）といくつかのシーケンス図（オプション）でマッピングされます。クラス図/シーケンス図を作成したら、モデルに基づいてコードを作成/生成します。1対多：複数のステップを1つのユースケースにマッピングします。以降の手順は同じです。
多対多：たとえば、ビジネスプロセスの1つのステップを2つ以上のユースケースでマッピングでき、同じ2つ以上のユースケースで他のステップとマッピングされます。
上記の方法はモデリングツールで実行できます。私の場合、私はSparx SystemのEnterprise Architectを使用しています。最近見つけて試用していますが、将来購入する予定です。 BPMN図の1つのステップで多くのユースケース図を整理し、クリックして必要なユースケースを表示できます。しかし、それが多対多のケースをサポートするかどうかはわかりません。
BPMNとユースケースを整理するための独自の方法を検討した後、インターネットを検索したところ、他の2つの論文が見つかりました。
各ユースケースをBPMNダイアグラムの各ステップに変換します。洗練されたユースケースがビジネスプロセスにどのように適合するかを視覚化します。ステップを含むビジネスプロセスをモデル化でき、後で各ステップをユースケースに変換できるため、このアプローチが気に入っています。 1つのステップは1つの使用例です。これは、上記の1対1のマッピングと同じです。元のプレゼンテーションはこちら： ユースケースセットをBPMNプロセスとして視覚化
![Use case - BPMN mapping]()
各ユースケースは、まさにビジネスプロセスです。ユースケースの各ステップは、ビジネスプロセスの各ステップです。オリジナルのペーパーはこちらです ビジネスプロセスとユースケースの説明
![Use case is a process]()
これらのアーティファクト（BPMNとユースケースおよびその他の図）を結合する標準化された方法はないように思えます。たぶん、それは管理上の問題であり、正式な手順に従うのではなく、創造的な使用法に依存しています。 これらの図を一緒に使用するとどうなりますか？
明確でないのは、ユースケースとUMLのどちらについて話しているのかです。
使用例：
ユースケースに関して：BPMNでは、それらを使用してBPMNを開発します。実際、ある程度まで、BPMNはいくつかのユースケースを置き換えることを意図しています。ユースケースは通常、開発者にビジネスプロセスを説明するために使用されますが、この場合、ビジネスアナリスト/ユースケースの作成者は、その「説明」の多くをBPMNに入れることができます。
残っているのは、アナリストがドキュメントに追加できるBPMNプロセスに関する詳細かもしれません。しかし、そのドキュメントでは、BPMNが説明されているものであることを明確にする必要があります（BPMNがテキストへの追加であることではありません）。
（これは、アナリストまたは開発者がBPMNを作成しているかどうかにも依存します。開発者がBPMNを作成している場合、開発者がBPMNを定義するのに役立つユースケースが明らかに必要ですが、少し奇妙です。効果的な組織では、ビジネスアナリストはBPMNの記述方法と記述方法を知っており、開発者はBPMNの再確認を支援できます。BPMNは、ある程度、開発者がビジネスロジックコードを記述せずに、アナリストに「記述」させることを目的としています。）
残すべき唯一のユースケースは、BPMNで完全にカバーされていない状況を説明するケースでなければなりません。例えば：
- WebページまたはUIの相互作用
- 複数のシステムが関与する技術的な使用例
- たとえば、Webサービスの説明。
BPMNの目的は、アプリケーション（コード）からビジネスロジックを削除することです。ビジネスロジックを記述するユースケースは、多くの場合、アプリケーションにbuildビジネスロジックintoに使用されます。つまり、両方を使用している場合は、どちらが定義を定義するかに関するルールを作成する必要があります。 （それ以外の場合は、同じプロセス/ロジックの競合する可能性のある説明が表示されます...）
ML：
UMLに関して：BPMエンジンがアクターになります。ユースケースの使用方法と同様に、UMLとBPMNの両方で同じことを記述しないことが重要です。それ以外の場合は、同じものの2つのわずかに類似しているが矛盾する説明がある可能性があります。
これは、ユースケースとは少しずれていると思います。ユースケースとBPMNは同じものをモデル化する2つの方法ですが、必ずしも文字どおりに翻訳することを意図しているわけではありません。 BPMNは、完全にマシンで実行可能なモデルを提供することを意図しています。人間に自然言語の説明を与えるためのユースケース。
ユースケースの説明（たとえば、ユースケースモデリング（Bittner et。al。））を見ると、それらはシステムとアクター間の対話であり、（シナリオ例を提供することにより）コンテキストに要件を配置しています。
これは、特定のユースケースモデルがビジネス全体をカバーするのではなく、要件を説明するためのビジネスの十分な量をカバーするかもしれないという問題を提示します。
したがって、BPMNで最も近いのはアクティビティではなく、コラボレーションと会話です。コラボレーションは、プール/参加者間の相互作用を示します。 （チェックアウト http://www.omg.org/spec/BPMN/20100601/10-06-02.pdf 。）
BPMNプライベート/内部プロセスとアクティビティは、参加者からの受信と入力に応じてビジネスが内部で何を行うかを示します。これは、統合モデルの分析モデルの境界、コントロール、およびエンティティを使用してシーケンス図を作成することに似ています。
BPMNパブリックプロセス http://www.omg.org/spec/BPMN/2.0/PDF/ セクション10.1.1.2は、外部プロセスでのアクティビティの使用を示していますが、内部アクティビティは表示されません。
図の例では、生徒を自分の参加者に分けてみてください。学生と大学の相互作用をモデル化します。次に、別の図で、各公共活動を実現する大学のプロセスをモデル化します。
あなたの質問がこのブログ記事で答えられることを願っています
[5] BPMNはUMLアクティビティ図を置き換えます。 UMLで現在定義されているアクティビティ図は廃止され、BPMN表記とセマンティクスに置き換えられました。 BPMNは本質的にUML動作の一部を置き換えます。
[6] BPMNはUMLを不要にするために成長しています。 BPMNは、ビジネス中心のモデリングとアーキテクチャに必要なすべての機能を包含するように成長し、UMLとの統合を冗長化します。 BPMNはいつか、UMLを置き換えるかもしれません。
[7] BPMNとUMLは、QVTでマッピングされた別個のモデルです。現在のように、BPMNとUMLは別個のメタモデルです。 BPMNのモデルの一部を使用してUMLモデルを作成し、UMLモデルの一部を使用してBPMNモデルを作成できるように、それらの間でQVTマッピングが指定されます。表記が同じではないため、表記はマップされません。
残念ながら、ここにいる全員が他の全員を修正しなければならないようです。それは正確には役に立ちません...
開発の初期に戻って定義された、完全に整ったユースケース、またはユーザーケースは、BPMNダイアグラムが想定されているほど堅牢ではありませんでした。これが、Alistair CockburnやIEEE Requirements Engineeringグループのその他の多くの人々が彼らを吹き飛ばした理由です。それらはより詳細で、異なるレベルがあり、PPT（People、Processes＆Technologies））を含めて機能要件を含める必要がありました。残念ながら、ユースケースでは同じレベルの詳細、および機能的なBPMNモデリングツールの各データ駆動型要素の背後にあるデータを含めることはできません。多くの場合、それらは同じことを言いますが、「モデル」は単なるモデルではありません。古いRational TUPを含む非常に少数のツール、口頭での使用例を上手に使用しており、Roseのモデルや内部の要素と結びつけるのは困難でした。EinarKarlsonは、キャリアのかなりの部分をSoDAと一緒にそれらの製品の出力に結び付けました。
BPMNやユースケースを具体化するために、ユーザーストーリーや「あまりにも詳細なビジネス要件」から始める方が簡単で早い場合があります。