アジャイルモデリング(AM)
公式サイト
モデリング成果物>ビジネスルール

ビジネスルールの概要

by Scott W. Ambler, Copyright 2003

ビジネスルールとは、ビジネスの1つの側面を定義あるいは制限するもので、ビジネス構造をはっきりさせたり、ビジネスの振る舞いに影響を与えたりするために作成します。ビジネスルールでは、アクセス権限に関する事柄に着目することがよくあります。たとえば、教授は、自分が教えているゼミを受けている学生の点数を入力したり修正したりすることができますが、他のゼミの学生の点数を入力することはできません。ビジネスルールには、ビジネス上の計算が含まれることもあります。たとえば、パーセントで表した学生のゼミの評価(91%など)を、文字で表した評価(A-など)に変換する方法などです。ビジネスルールの中には、組織の方針に着目したものもあります。大学の方針として、同じ学期のうちに2つ以上のコースで不合格になった学生を1年間停学にするというものがあるかもしれません。

図1. ビジネスルールの例 (要約形式)

  • BR123 教授は学生の評価をつけることができる。
  • BR124 教授から権限を認められた助手は学生の評価をつけることができる。
  • BR177 数値の評価と文字の評価を変換するための表。
  • BR245 修士過程には論文の提出を含まなければならない。

 

図1にはいくつかのビジネスルールの例をまとめました。ビジネスルールそれぞれに一意の識別番号が付いていることに注意してください。私は「BR#」という命名規則を使っていますが、自分の好みの方法で番号をつけてかまいません。一意の識別番号を付けることで、クラスモデルユースケースといった他の開発成果物の中から、簡単にビジネスルールを参照することができます。

状況によっては、ビジネスルールを非常に簡単に、1つの文で記述できることがあるでしょう。また、そうでない場合もあります。図2に示すのは、BR123を完全に文書化した1つの例です。この図にはいくつかのセクションが含まれています。

  • 名前:名前をつけることでビジネスルールの主題が分かりやすくなります。
  • 概要:この概要でルールを厳密に定義します。私は文章でルールを記述しましたが、フローチャートUMLアクティビティ図などの図を使ってアルゴリズムを記述したものもよく見かけます。その他には、オブジェクト制約言語(Object Constraint Language : OCL)ILOGルール言語ビジネスルールマークアップ言語(Business Rules Markup Language: BRML)といったビジネスルール言語を使うこともできます。アジャイルモデリングが推奨しているように、自分の状況に合わせて適切な成果物を使ってください。
  • 例(オプション):例を示すことでルールが明確になります。
  • 情報源(オプション):必要なら確認できるようにルールの情報源を示します(ルールの情報源が人─たいていはプロジェクトの利害関係者─や人のチームであることはきわめて一般的です)。
  • 関連ルール(オプション):関連するルールがあればその一覧を記述しておくことで、ルール間を辿ることができます。
  • 改訂履歴(オプション):変更が行なわれた日時、変更を行なった担当者、変更の内容を示します。

 

図2. 詳細なビジネスルール

名前:

教授は学生の評価をつけることができる

識別番号:

BR123

概要:

自分だけが教えているゼミの学生の評価を、教授だけが最初に入力したり変更したり削除したりすることができる。それかできるのは、ゼミが行なわれている学期の間だけである。

例:

「生物301 ガンマ放射線の先進的利用」を教えているBruce博士は、そのゼミに登録している学生全員の評価をつけることができるが、Peter博士が教えている「生物302 クモ類に対する放射線の影響」に登録している学生の評価をつけることはできない。

情報源:

大学方針および手順

文書番号: U1701

発行日: 2000/8/14

関連ルール:

BR12 終身教授の資格条件

BR65 ゼミの有効期間

BR200 学生の最終評価の変更

改訂履歴:

作成 2001/3/2 作業者: D. Prince

更新 2001/10/10 関連ルールBR200の参照を追加 作業者: G. Stacy

 

 

図2は明らかに文字が多すぎます。ほとんどのプロジェクトチームではここまで書く必要はありません。よりアジャイルなやり方をするなら、ビジネスルールの名前と番号と概要をインデックスカードに書くだけしておきます。もう少しきれいにしたければ、ビジネスルールをWikiページ(www.wiki.org)やワードプロセッサに打ち込んでもよいでしょう。モデルをできるだけ簡潔にしておくことを忘れないでください。

ビジネスルールは、要求収集や分析を通常どおり行う中で見つかります。ユースケースやユーザストーリーなどを使って利用に即した要求のモデリング(usage modeling)を行なっている間に、ビジネスルールが明らかになることがよくあります。目安として、何かが計算や組織の運用原則について定義していたら、おそらくそれはビジネスルールとして文書化する対象と考えられます。ビジネスルールと他の要求成果物とを分けた方がよいのは、他の成果物の中でビジネスルールが何度も参照される可能性があるからです。たとえば、BR129は、「ゼミに学生を登録する」ユースケースで参照されていますが、おそらくはクラスモデルや、もしかするとソースコードからも参照されるかもしれません。ただし、ビジネスルールやユースケースが少ししかないのであれば、ユースケース中にビジネスルールを記述することもできます。経験則として、最初はユースケース中に含めておき、ビジネスルールが明らかになった時点で、あるいは含めるのが難しくなれば、分けるとよいでしょう。難しくなるというのは、ビジネスルールが多すぎてユースケースのほとんどを占めるようになったり、同じビジネスルールが2つ以上のユースケースで参照されるといった場合のことです。

優れたビジネスルールはよくまとまっているものです。別の言い方をすると、1つの概念だけを記述するということです。ビジネスルールのまとまりを高くしておけば、定義しやすくなり、再利用される可能性が高くなります(成果物─他のビジネスルールを含む─でビジネスルールを参照すれば、それは効果的に再利用されています)。ただし残念なことに、ビジネスルールは1つの事柄にそれぞれ集中するべきなので、たいていは非常に多数のルールを識別しなければならなくなります。

Ronald Ross (2003)は、彼が「ビジネスルールアプローチ」と呼ぶいくつかの基本原則について説明しています。彼はルールについて次のように考えています。

  • 明示的に記述されていること
  • 明解な言語で表現されていること
  • 手続きやワークフローとは独立していること(例:複数のモデル)
  • 事実にもとづいていること。事実は用語に表される概念にもとづいていなければならない(例:用語集)
  • 望ましい方向に振る舞いを導く、あるいは影響を与えること
  • 識別可能で重要なビジネス要素によって動かされていること
  • 権限を持つ関係者が利用できるようになっていること(例:共同所有)
  • 情報源が1つであること
  • 関連知識を持った人が直接記述すること(例:利害関係者の積極的な参加)
  • 管理されていること

ビジネスルールの多くは、事実上制約事項であると考えることができ、実際に制約事項は、技術上、ビジネス上のどちらの事柄にも適用されます。UMLでは、ビジネスルールはオブジェクト制約言語(OCL) (Warner and Kleppe 1999)を使って図上に記述されることが多く、この2つの概念の違いについて余計に混乱を引き起こす可能性があります。気にしないでください。大切なのは要求事項を明らかにして理解することであり、分類することではないのですから。

 

 

注: この成果物の説明は『The Object Primer 3rd Edition: Agile Modeling Driven Development with UML 2』より抜粋しました。


推奨文献

 

その他の文献

アジャイルモデリング(AM)について詳しく知るにはこの本をお薦めします。

 アジャイルモデリング

 

Let Us Help (以下、北米での話ですのでご注意ください)

Ronin International, Inc. continues to help numerous organizations to learn about and hopefully adopt agile techniques and philosophies.  We offer both consulting and training offerings.  In addition we host several sites - Agile Modeling, Agile Database Techniques, UML Modeling Style Guidelines, Enterprise Unified Process (EUP) - that you may find of value.

You might find several of my books to be of interest, including The Object Primer, Agile Modeling, The Elements of UML Style, and Agile Database Techniques.

For more information please contact Michael Vizdos at 866-AT-RONIN (U.S. number) or via e-mail (michael.vizdos@ronin-intl.com).

 

visits since November 17, 2003.