BPMN（Business Process Modeling Notations）は、視覚化によってビジネスプロセスをモデル化するために使用されます。したがって、BPMNダイアグラムの表現を通じて、無形のアイデアを物理的に具体的にします。問題は、UMLを使用してBPMNをどのように編成するかです。
最初に、ユースケースとビジネスプロセス図を整理する2つの方法を考えました。
1対1/多：ビジネスプロセス図の各ステップ（
stepここではBPMNダイグラムの各ノードを意味します）を1つまたは複数のユースケースにマッピングします。各ユースケースは、関連するいくつかのクラス図/コンポーネント図（入力と出力を持つ1つのコンポーネントにクラスのセットをカプセル化できるため、これが好きです）、いくつかのシーケンス図（オプション）にマップされます。クラス図/シーケンス図を作成したら、モデルに基づいてコードを記述/生成します。多対1：複数のステップを1つのユースケースにマッピングする。サブシーケンスの手順は同じです。
多対多：たとえば、ビジネスプロセスの1つのステップを2つ以上のユースケースにマッピングし、同じ2つ以上のユースケースを他のステップにマッピングすることができます。
上記の方法はモデリングツールで実行できます。私の場合は、SparxSystemのEnterpriseArchitectを使用しています。最近発見し、試用版を使用していますが、将来購入する予定です。BPMN図の1つのステップで多くのユースケース図を整理でき、クリックして必要なユースケースを表示できます。しかし、それが多対多のケースをサポートするかどうかはわかりません。
BPMNとユースケースを整理するための独自の方法を考えた後、インターネットを検索したところ、他に2つの論文があり、それぞれが次の方法を提案しています。
各ユースケースをBPMN図の各ステップに変換します。洗練されたユースケースがビジネスプロセスにどのように適合するかを視覚化します。ステップを含むビジネスプロセスをモデル化でき、後で各ステップがユースケースに変わるため、このアプローチが気に入っています。1つのステップは1つのユースケースです。これは、上記の1対1のマッピングと同じです。元のプレゼンテーションはこちら：ユースケースセットをBPMNプロセスとして視覚化する
各ユースケースはまさにビジネスプロセスです。ユースケースの各ステップは、ビジネスプロセスの各ステップです。元の論文はこちら：ユースケースを使用したビジネスプロセスの説明
これらのアーティファクト（BPMNとユースケースおよびその他の図）を接着する標準化された方法はないように思われます。多分それは管理上の問題であり、正式な手順に従うのではなく、創造的な使用法に依存しています。ソフトウェアエンジニアリングプロセスでのこれらの図の使用について、あなたの意見/経験は何ですか？
私は、ソフトウェア開発プロセスで独自のプラクティスを指定するXPのような方法論を知っています。ただし、管理の側面に重点を置いているスクラムとは異なり（つまり、BPMN / UMLモデリングを作業プロセスに適用できます）、XPはソフトウェアプラクティスを指定し、従う必要があり、BPMN/UMLなどのモデリングプロセスを排除します。その慣行が適切に適用されない場合、ドキュメントの下にあるような問題が発生し、不十分なソフトウェア設計が組み込まれます。
XPよりもモデル駆動型の方法が好きです。企業や人の好み次第だと思います。アジャイルの目標の1つは、「開発者をドキュメント作業から解放する」ことです。XPのような方法論は、ドキュメントの下に簡単につながるようです。その目標を達成するための解決策は、既存の図から情報を収集し、レポート（この場合はRTF、PDF、HTML）を自動的に生成することで、開発者がドキュメントを書く作業量を減らすのに役立つツールを実装することです。 Sparxシステムのエンタープライズアーキテクトの）。もう1つの例は、図の描画に時間がかかると不満を言う人が多いことです。私の意見では、解決策は図を描くことではなく、ツールを使用することです。今日のモデリングツールは、コードと図を同期できるラウンドトリップエンジニアリングをサポートしています。この問題についてのあなたの意見/経験は何ですか？