web-dev-qa-db-ja.com

プロセスモデリング表記の選択

この質問が本当にここに属しているかどうかは疑わしいですが、いずれにせよ、StackOverflowや他のStackExchangeサイトには当てはまりません。だからここに行きます。

目的

私の現在のペットプロジェクトは、ビジネスプロセス仕様からコードを生成するソフトウェアツールの開発にあります。

プログラムの入力は...

  • プロセス図（もちろん、非常に詳細なものです！）
  • 必要に応じて、これらのアクティビティを自動化するためのユーザーインターフェイス
  • 既存または後で構築されるサードパーティプログラムとのインターフェイスの識別

そして、プログラムの出力は...

  • テーブル、ビュー、およびストアドプロシージャの作成スクリプト
  • アプリケーションコード（CRUD、プロセス/アクティビティ/ユーザー間の情報フローなど）

問題

さて、私はまだどのプロセスモデリング表記法を使用すべきかわかりません。

代替案

個人的には、構造が単純なため、EPC（イベントプロセスチェーン）図が非常に好きです。

  • プロセスフローはイベントで開始し、イベントで終了する必要があります。複数の代替ブランチがある場合、このルールはすべてのブランチと可能なフローに適用されます。

  • イベントは、0個以上のアクティビティをトリガーする場合があります。それらがゼロアクティビティをトリガーする場合、それらは最終イベントです。それらが2つ以上のアクティビティをトリガーする場合は、ブランチオープニングを使用する必要があります。

  • 完了すると、アクティビティは1つのイベントをトリガーする必要があります。

  • アクティビティは、1つ以上のイベントによってトリガーされる場合があります。それらが2つ以上のイベントによってトリガーされる場合は、ブランチクロージングを使用する必要があります。

  • プロセスフローの説明を完了した後、他のすべて（つまり、イベントまたはアクティビティではないもの、たとえば、人員、リソース、物理的な資料、情報）を追加できます。

ただし、少なくとも私が知っている他のソフトウェア開発者から判断すると、EPC図は人気がありません。他の誰もがBPMNを使用しているようです。これはもちろん、機能/責任の側面（つまり、各アクティビティを実行する人）を説明するのに優れていますが、レーンが邪魔になるため、他のすべてにとって恐ろしいものです。

制約

私が知っているが明示的に拒否した他の表記法は...

  • MLシーケンス図：代替フローごとに図を作成する必要があるため、そのコストは私のツールのユーザーにとって法外なものになります。

  • IDEF： IDEF0は情報フローのマッピングに最適ですが、IDEF3は恐ろしいプロセスフロー表記です。このレベルではgotoを許可しないでください。

質問

どのプロセス表記を使用しましたか？私のプロジェクトに私を推薦するのはどれですか？

business-processnotationmodelingbpmn
2
pyon

どのプロセス表記を使用しましたか？

UMLとBPMN。

私のプロジェクトに私を推薦するのはどれですか？

どちらでもない。

実際の詳細を掘り下げ始めると、グラフィカルなビジネスプロセス表記が乱雑になり、操作が困難になります。

プログラミング言語を進化させたのは、グラフィック表記が粗すぎて実際には役に立たないためです。

基本的に、ビジネスプロセスは一種のプログラミング言語であり、多数の事前定義されたクラスとオブジェクトを備えた既存の言語は、山のような写真よりも明確な場合があります。

明確なDSL（XMLベースではない）は、グラフィックスよりも役立つ場合があります。

http://www.dsmforum.org/events/DSM09/Papers/Barzdins.pdf

http://www.yawlfoundation.org/

（はい、YAWLはXMLベースですが、それは完全に悪ではなく、XMLと図を作成するYAWLのPythonのような構文を作成できます。いいえ、私はそれをしていませんが、そうすべきではありませんthat難しい。）

4
S.Lott