サイト命名規則プロセス定義の各要素は、名前を持ちます。言語キーワードを使用できないことと、同じプロセス図内に同名の要素を2つ以上使用できないことです。呼ぶ変数を持つことはできません。それらが別々のプールにあったとしてもです。呼ぶアクターをもつことは可能です。デザイナー間で共有できません。デザイナー内ではページ間でも変数は共有できません。デザイナー内の変数の使用に関する詳しい情報は「変数」を参照してください。比較的単純なプロセスでも、名前の数はすぐに多くなります。戦略的な命名方針を決めておくことは、プロセスの可読性と保守性を高め、要素の再利用が容易になります。次の「ベストプラクティス」を提案します。意味が分かる名前を付けることです。この目的は、コードをあえて解読しなくても何をするのか分かるようにすることです。短い名前よりも長く、意味が分かる名前の方がベターです。場合、名前は1度だけタイプインする必要がありますが、その後はリストから選択できます。したがって、短い名前を使用するメリットはありません。状態を意味する「申告された領収書がある」の方がベターです。名前は、「何のことなのか」、あるいは「それは何をするのか」を示すことができます。変数に対しては、「それはどんなものか」、「すなわち、~のこと」、「それは何をストアしているのか」を示すことがさらに有益です。プロセス内部、および複数のプロセス間でも再利用やコピーを活用し整合性を持たせることです。再利用やコピーしたい要素を探し出すことが簡単なら、再利用の可能性は高くなります。プール名は高位のビジネスプロセス名を使って命名することです。ビジネスプロセスにいくつかのプールがある場合、それらのプールがどのように関係しているかを告げる名前を使用します。レビュー」、「休暇申請のエスカレーション」と呼ぶことになります。レーンにはプロセスを遂行する人を示す名前を付けます。一般的には、アクター名を使用し、同じレーンには同じアクターでアクティブをグループ化すべきです。このさらなる利点はプロセス図中でアクターを見えるようにすることです。タスクは「何をするか」(つまり動詞を使う)を明確に示すように名前を付けます。タイプにとって重要です。「AをBする」あるいは「AのB」)を適用し、統一した動詞句を用います(この場合、レーン名に記されたアクター名が主語になります)。休暇申請プロセスの例にとると、それらのタスクを「マネージャが申請をレビューする」や「人事がレビューする」とは呼びません。前者は主語が余計、後者は対象が不明です。ゲートウェイには、「判定する事」を名前に付けます。ゲートウェイからの流出シーケンスフローは除く)。終了イベントの名前は、「終了した状態」、できれば「その理由」を示すべきでしょう。いくつかのフローを持つプロセスでは、それぞれのフローがどのような状態で終了するのか知る必要があります。「休暇申請のマネージャレビュー終了」や「休暇申請の承認却下終了」などの例です。変数は、プロセスデータとタスクデータの間で違いを付けます。すべてのプロセスデータ名に「p_」、すべてのタスクデータ名に「t_」、の接頭辞を付けて識別できるようにします。変数とパラメータは、その名前の中でデータ型を暗黙的に示すようにします。用語をそれとなく使用し行います。データ型をそれとなく示すこともできます。コネクタのインスタンスには、コネクタの種類ではなく、それが「何を行うのか」を示す説明的な名前を付けます。プロセスが同じコネクタをいくつかの箇所で異なるデータを取り扱う場合、これは特に重要になります。いう名前を付けることが可能です。スクリプトなど)には、その目的を示す説明的な名前を付けます。ビジネスプロセス内ではユニークな名前を使用します。スクリプトやデータ型定義)のライブラリを作成済みの場合、その各標準要素は、明快に理解できる説明的な名前を付けます。(日本語なら「変数マップから操作リストを作成」)です。再利用可能な標準要素をプロセス内にインポートし変更して利用する場合は、その変更済み要素の使用プロセスが特定可能で、かつそのリポジトリ内でユニークな新しい名前で保存します。この規則を適用するによって、これらの標準要素を個別改修する場合、標準要素を上書きしてしまう危険を回避できます。標準要素を使用している既存のプロセスに問題を波及させないようにすることです。アプリケーション名、タスク名、またはプロセス名で使用できない次の禁止キーワードがあります。これらの禁止キーワードは、いずれも大文字、小文字の区別はありません:contentthemeapiあらかじめ決めた命名規約の使用に加え、プロセス内の各要素に説明を記述することによって、そのプロセスの保守性を改善できます。プロセス図上にテキスト注釈を使用することも可能ですが、あまり長いテキスト注釈は、逆にそのプロセス図を読みにくくします。したがって、テキスト注釈は主として、訂正または完遂すべき何かを一時的に書き留めるため、あるいはビジネスアナリストとアプリケーション開発者間のコミュニケーションのために使用することを推奨します。メールアドレスキャンセル投稿を送信できませんでした。メールアドレスを確認してください。メール送信チェックに失敗しました。このブログではメールでの投稿共有はできません。