uml - BPMNの長所と短所は？

Question

開発者の観点から見たBPMNの長所と短所を教えていただければ幸いです。

私はUMLとBPMNを比較していますが、UMLには多くの長所と短所がありますが、BPMNにはありません。

Answer 1

それは主に聴衆と目的にかかっています。モデリング言語に関しては、BPMN と UML のアクティビティ図は、異なる表記法でほぼ同じ概念空間をカバーしています。表記法はすぐに宗教的になります。個人的には BPMN よりも AD 表記の方が好きですが、これは非常に個人的なことです。

大まかに言えば、BPMN は、ビジネス プロセス モデリング / ビジネス分析のバックグラウンドを持つ人に好まれる傾向があります。UML AD は、ソフトウェアの観点から来る人に好まれる傾向があります。ツールのサポートはこれを反映する傾向があります。ハイエンドのプロセス モデリング ツール (casewise、aris など) は BPMN をサポートする可能性が高くなります。ソフトウェア モデリング ツール (MagicDraw、Sparx など) は UML を支持します。しかし、そこにはクロスオーバーが増えています。どちらの場合も問題なく、ビジネス関係者と両方を使用しました。

最後に目的です。ダイアグラムは、人間が使用するためだけに使用される予定ですか、それとも何らかの形式の分析/コード生成の仕様として使用されますか? 写真だけでない場合は、ツール チェーンが決定的な要因になる可能性があります。

違いの詳細な説明が必要な場合は、このフォーラム投稿の回答をご覧ください。

Answer 2

新しい BPMN プロファイルが OMG で議論されました。UML は、アクティビティ図や状態図でも簡単にコードを生成できます。モデルにステレオタイプを追加するだけで、パーサーが xmi を取得してコードを作成します。OMG 仕様では、使用するステレオタイプとその理由を定義します。本当に良いアイデアです!!

私の会社では、BPMN の使用をやめ、標準言語の上に構築されているため、より正確なアクティビティ図のみに焦点を当てています。クラス図、ユースケース図、アクティビティ図もあると、モデル化を高速化できます。アクティビティ図または状態図から実行中のコードを取得します。クラス図でデバッグします。すべてのダイアグラムに同じメタモデルを使用するため、アクティビティをコード実装まで追跡し、クラス ダイアグラムを介して追跡できます。つまり、コードが生成されると逆になり、より優れたオブジェクト アーキテクチャを実現するために、すべての要件とアーキテクチャをチェックします。すべてがうまく機能します:-)

現在、新しいプロファイル仕様を待っており、BPMN をカバーするために必要なステレオタイプを実装します。あなたの質問に対する私の答えは、もう BPMN は必要なく、UML 2.3 BPMN プロファイルの実装に進むべきだということです。

Answer 3

BPMNは、ビジネスプロセスフローをモデル化するためのものですよね。それはUMLの目的ではありません。UMLの目標は、ソフトウェアをさまざまな視点からモデル化することであり、最終的にはそれをコーディングする必要がないことです（そう、それは一種の理想です）。