ODM V8.8 アプリケーション・デザイン・ガイド€¦ · 参考資料参考とした資料のリンク、または、名前。プロジェクト名 : ドキュメント名

プロジェクト名 : ドキュメント名 : ODMアプリケーション・デザイン・ガイド

- 1 -

ODM V8.8 アプリケーション・

デザイン・ガイド


- 2 -

1 はじめに ........................................................................................................................................................ 4

1-1 目的 ............................................................................................................................................................ 4 1-2 範囲 ............................................................................................................................................................ 4 1-3 対象者 ........................................................................................................................................................ 4 1-4 前提資料 .................................................................................................................................................... 4 1-5 用語・略語 .................................................................................................................................................. 5 1-6 アーキテクチャー上の決定 ....................................................................................................................... 5

2 ODM 開発概要 .............................................................................................................................................. 6

2-1 ODM におけるルール開発ツール ............................................................................................................ 6 2-2 ルール・アプリケーション開発を始めるにあたって .................................................................................. 6 2-2-1 ルール・アプリケーションの設計要素 ................................................................................................... 6 2-2-2 ルール・アプリケーション開発の前提成果物 ....................................................................................... 7

3 設計 ............................................................................................................................................................... 9

3-1 インターフェース ...................................................................................................................................... 10 3-1-1 ルール・セットの単位 ........................................................................................................................... 10 3-1-2 ルール・セット・パラメーターの方向 ..................................................................................................... 11 3-1-3 ルール・セット実行前のデータ準備 ..................................................................................................... 12 3-2 構造化 ...................................................................................................................................................... 15 3-2-1 プロジェクトの分割 ............................................................................................................................... 15 3-2-2 プロジェクトの共有 ............................................................................................................................... 16 3-3 語彙 .......................................................................................................................................................... 19 3-3-1 BOM クラスの階層 ............................................................................................................................... 19 3-3-2 BOM と XOM の設計アプローチ ......................................................................................................... 20 3-3-3 XOM の開発言語 ................................................................................................................................. 21 3-3-4 拡張性を持たせたデータ構造設計 ..................................................................................................... 22 3-4 ドメイン ..................................................................................................................................................... 23 3-4-1 静的ドメインと動的ドメイン .................................................................................................................. 23 3-4-2 参考：静的ドメインの作成例 ................................................................................................................ 24 3-4-3 参考：動的ドメインの作成例 ................................................................................................................ 28 3-4-4 HINT&TIPS.............................................................................................................................................. 36 3-5 変数 .......................................................................................................................................................... 40 3-5-1 ルール・セット変数 ............................................................................................................................... 40 3-5-2 ルール・セット・パラメーター .................................................................................................................. 41 3-5-3 バインディングによる変数 ................................................................................................................... 42 3-6 実行モードと繰り返し処理 ...................................................................................................................... 44 3-6-1 実行モード ............................................................................................................................................ 44 3-6-2 繰り返し処理 ........................................................................................................................................ 48 3-7 エラー処理 ............................................................................................................................................... 54 3-7-1 NPE ........................................................................................................................................................ 54 3-7-2 HINT&TIPS.............................................................................................................................................. 63


- 3 -

3-8 ログ出力 ................................................................................................................................................... 67

4 開発（編成） .................................................................................................................................................. 68

4-1 ルール化方針 .......................................................................................................................................... 69 4-1-1 ビジネス・ロジックの定義方法 ............................................................................................................. 69 4-2 ユーティリティー ........................................................................................................................................ 71 4-2-1 UTILITY クラスの作成 ............................................................................................................................ 71 4-2-2 UTILITY クラスの配置 ............................................................................................................................ 74

5 テスト ........................................................................................................................................................... 76

5-1 テスト方針 ................................................................................................................................................ 76 5-1-1 テスト種別ごとのスコープ .................................................................................................................... 76 5-1-2 ルール・オーナーによる単体テストの実施単位 ................................................................................. 77 5-1-3 ルール開発チームによる単体テストの実施単位 ............................................................................... 78 5-2 TIPS ............................................................................................................................................................ 78 5-2-1 問題の分類 .......................................................................................................................................... 78 5-2-2 シナリオ・ファイル・テンプレートの「予期した実行の詳細」 ................................................................. 79

6 配布 ............................................................................................................................................................. 80

6-1 ルール・セットの配布 ............................................................................................................................... 80


- 4 -

1 はじめに

目的本書は、IBM Decision Server Rule Designer (以下 Rule Designer) V8.8 で開発し、IBM Operational Decision Manager (以下 ODM) V8.8 で稼働させるルール・アプリケーションの開発指針および開発標準について記述する。本書の指

針・標準に従ってルール・アプリケーション開発を実施することにより、開発作業の効率化と品質確保を目的とする。本書では意思決定サービスおよび意思決定エンジンの利用を前提とする。

範囲本書では、Business Rule Management System(以下 BRMS)をベースとしたルール・アプリケーション開発の標準化に

ついて言及する。

対象者本書の対象者はアーキテクト、ルール・アプリケーション設計者、ルール・アプリケーション実装者とし、以下のスキル・

レベルを前提とする。・ BRMS の基礎知識を有すること・ Rule Designer を使用して簡単なルール・アプリケーションを作成できること

前提資料本書では、ODM の基礎知識を有することを前提として記述する。技術情報は下記サイトを参照のこと。 IBM Operational Decision Manager Knowledge V8.8.0 http://www.ibm.com/support/knowledgecenter/SSQP76_8.8.0/com.ibm.odm.distrib/kc_welcome_odm_distrib.html IBM developerWorks Japan : Decision Management https://www.ibm.com/developerworks/jp/websphere/category/decman/

http://www.ibm.com/support/knowledgecenter/SSQP76_8.8.0/com.ibm.odm.distrib/kc_welcome_odm_distrib.html

https://www.ibm.com/developerworks/jp/websphere/category/decman/


- 5 -

用語・略語以下に本書で使用する用語および略語を示す。その他の用語や、各語の詳細な説明は前提資料を参照のこと。

略語説明 BRMS Business Rule Management System ODM IBM Operatinal Decision Manager Rule Designer IBM Decision Server Rule Designer

アーキテクチャー上の決定本書では、「アーキテクチャー上の決定」を記述する。「アーキテクチャー上の決定」とは、アーキテクチャーに関する重要な決定事項とその理由を文書化するワーク・プロダ

クトである。目的は、1. アーキテクチャーに関する重要な決定事項が一元的にまとめられていることを保証し、2. 同じ

問題を再度検討しないことを保証し、ソリューションのアーキテクチャーに一貫性を保つことである。ポイントは、1. ソリ

ューションを決定する上で重要なアーキテクチャーに関する決定事項を文書化し、2. 決定事項もさることながら、判断

した理由が大切であり、代替案とともにその判断理由を残し、3. 文書化した内容を、今後参加する人が参照可能とな

るように管理することである。以下に本書で使用する「アーキテクチャー上の決定」のテンプレートを示す。対象分野対象の製品における設計要素トピック章タイトルタイトル節タイトル Id. AD-ODM-XXYY 説明決定しようとしていること、解決しようとしている問題。前提問題について正しいと思われているもの。前提がなくなると、解決策の候補が実現しなくなる。制約解決策の候補に対する制約または制限。制約がなくなると、解決策の候補が増える。要件この決定が重要である理由。基準候補を比較して、決定するための基準。候補考慮される解決策のオプションとその説明の一覧。決定解決策の候補の中からの決定。可能であれば、関連する成果物への参照。決定理由決定の理由、および、それを支える原理や準拠からの逸脱の説明。影響派生要件決定により派生して生まれる要件。関連 AD 派生要件おける AD についての、ID とタイトル。（※関連＝依存関係とする）参考資料参考とした資料のリンク、または、名前。


- 6 -

2 ODM 開発概要

ODM におけるルール開発ツール IBM Operational Decision Manager は、以下のコンポーネントで構成される。 • ルールの開発・メンテナンス環境

Rule Designer Decision Center Rule Solutions for Office

• ルールの実行環境 Rule Execution Server

• ルールの継続的テスト実行・管理機能 Decision Center

ルール開発・メンテナンス用ツールとして提供している３種類の製品・ツールは、それぞれ想定するユーザーが異な

り、以下の通り。 • ビジネス・ユーザー向け：

Decision Center Rule Solutions for Office

• IT ユーザー向け： Rule Designer

本書では、IT ユーザー向けの Rule Designer を特に取り上げて説明する。 Rule Designer を利用して、ルール・アプリケーションのモデリングからコーディング、デバッグ、導入にいたるまでを１

つのプラットフォームで行うことができる。 • アプリケーションのコードとルールの開発を一つの統合開発環境で実施可能 • テスト、デバッグ、リファクタリングまでを含む反復型開発を実施可能 • ソース・コード管理システムとの連携可能 • Decision Center との同期が可能 • ビジネス・オブジェクト・モデル（以下 BOM）開発、プロジェクト・テンプレート、ウィザードを活用し、ルール・ベース

のアプリケーション開発を短期間で習得することが可能

ルール・アプリケーション開発を始めるにあたってここではルール・アプリケーションを開発する前に必要となる設計要素とそれらがどのような前提成果物から設計される

かについて簡単に解説する。

ルール・アプリケーションの設計要素ルール・アプリケーションを開発するに当たって必要となる設計要素について記述する。


- 7 -

・ルール・プロジェクト

ルール・アプリケーションを作成する上で基本となる単位で Eclipse のプロジェクトの一種である。各種ルール成果物、

ビジネス・オブジェクト・モデル（BOM）、語彙、実行オブジェクト・モデル（XOM）への参照などを含む。・ルール・セット

ルール・エンジンによる実行が可能な一連のルール。ルール・アーティファクトおよび非ルール・アーティファクトを含

めることができる。Rule Designer で開発したルール・プロジェクトから意思決定に必要なルールを抽出してルール・セッ

トに格納する。

・実行オブジェクト・モデル（XOM）ルールが実行される際のオブジェクト・モデルで、アプリケーションのオブジェクトやデータを参照する。Java クラス

（Java 実行オブジェクト・モデル）か XML Schema（動的実行オブジェクト・モデル）で構築される。・ビジネス・オブジェクト・モデル（BOM）

ビジネス・ルールのオブジェクト・モデルで、ルール内で使用する用語や振る舞いを定義する。XOM で定義したフィー

ルドやメソッドと語彙を結びつけることで自然言語的な語彙を使用してシステム的に実行可能なルールを記述すること

ができる。

・ルール・フロールール実行を制御する方法で、実行するルールとルール間の順序を定義する。ルール間に呼び出しの依存関係など

がある場合はこのフローによって実行順序を制御することができる。・ルール成果物

ビジネス・ルールを記述するもので、ビジネス・ルール、意思決定表、意思決定ツリーの 3 種類の実装方法がある。記

述するルールは基本単位に洗練しておくことで、ルール間の重複を排除、ビジネス・ルールの一貫性を確保、ルール

間のギャップを埋めることができる。

ルール・アプリケーション開発の前提成果物上述した設計要素を設計する上で必要となる前提成果物について記述する。すべて充足する必要はないが、作成し

ない場合には代替する成果物などを準備する必要がある。・ユースケース・モデル、ユースケース仕様

システム化対象範囲の特定や要件の整理、テスト・シナリオの作成など様々な用途で利用する。アクターとシステムとの関係からルール・プロジェクトの作成単位の候補にもなりえる。・論理データ・モデル

クラス図や ER 図など。XOM や BOM を作成するために利用する。ここでは、振る舞いを定義することができ、Java 実

装の XOM を作りやすいという点からクラス図を利用する。用語集で整理される語彙との関連の整理も行う。・用語集

ビジネス上の語彙を整理することで、BOM の言語化を体系的に行うことができるようになる。名詞（データ項目）だけで

なく、動詞（振る舞い）についても整理することが必要である。・ルール記述文書

ビジネス・プロセス・モデルやユースケース、業務規定集や既存システムなどから抽出されたビジネス・ルールをまとめ

たもの。ルール間の依存関係などを整理し、ルール・フローやルール・パッケージの設計も行う必要がある。


- 8 -

・アーキテクチャー上の決定本書で扱っている内容であり、ルール・アプリケーション開発におけるアーキテクチャーを決定する。・テスト・シナリオとテスト・データ

作成するルール・セットをテストするシナリオとそのシナリオを実現するデータである。繰り返しテストを行うことで品質を

向上させるとともに、ルール開発に先立ってテスト・シナリオを整理することで、ルール仕様の妥当性の確認にもつな

がる。ここで用意したテスト・データなどを実際に使って、作成したルールのテスト実行やデバッグを行う。


- 9 -

3 設計


- 10 -

インターフェースルール・クライアントからの呼出しのインターフェースは、設計の初期に決定する必要がある。具体的には、ルール・セ

ットの単位をどうするか、ルール・セット・パラメーターをどう設定するかなどである。

ルール・セットの単位 ODM では、ルール・セットの単位が、ルール・クライアントからの呼出し単位になる。よって、ルール・クライアントからの

呼出しを考慮して、その単位を決定する必要がある。ここで、業務の観点でのルールの塊をルール・サービスとする。例えば、融資業務であれば、融資審査を行う塊とし

て、検証→計算→資格→保険の一連のルール・タスクを、ルール・サービスの単位として考える。ルール・サービスを

中心に考えると、以下の 3 つの候補が考えられる。候補(1)は、複数のルール・サービスを 1 つのルール・セットに統合する場合である。例としては、融資審査サービスに

加えて、保険金支払サービスも統合する場合などである。候補(2)は、1 つのルール・サービスを 1 つのルール・セット

にする場合である。候補(3)は、ルール・サービスを分解して、ルール・タスクの単位でルール・セットを構成する場合で

ある。例としては、検証→計算→資格→保険のルール・タスクを１つ１つに分割する場合などである。それぞれの候補について、機能性、効率性などの観点から検討する必要がある。

図 3-1-1 ルール・セットの単位

対象分野ルール・セットトピック設計タイトルルール・セットの単位 Id. AD-ODM-0311 説明ルール・セットの単位を決定する。前提ルール・セットの単位が、ルール・クライアントからの呼び出しの単位である。制約要件ルール・セットの単位が変わると、インターフェースや呼び出しのアーキテクチャーが変わってしまう。

基準 (A) 機能性 (B) 効率性 (C) 保守性

候補 (1) 複数のルール・サービス (2) ルール・サービスの単位 (3) ルール・タスクの単位

決定 (2) ルール・サービスの単位

(1) 複数のルール・サービス (3) ルール・タスクの単位(2) ルール・サービスの単位

開始

終了

タスクB

タスクC

開始

終了

タスクB

タスクC

開始

終了

タスクA

タスクB

分岐

開始

終了

タスクA

タスクB

分岐

開始

終了

タスクA

開始

終了

タスクA

開始

終了

タスクB

開始

終了

タスクB

開始

終了

タスクC

開始

終了

タスクC

タスクB

タスクC

開始

終了

タスクA

タスクB

分岐

分岐

タスクB

タスクC

開始

終了

タスクA

タスクB

分岐

分岐

（サービス1）（サービス2）

（サービス1）（サービス2）


- 11 -

決定理由

重視する基準：(A)、(B) <(1)の短所>ルール・サービス自身とは関係ない制御用のルール・セット・パラメーターが必要にな

り、機能性が低い。 <(2)の長所>(1)と比較して、ルース・サービスのための必要最低限のルール・セット・パラメーターの

みで十分なため、機能性が高い。また、(3)と比較して、ルール・フローの中でルール・タスクを統合

するため、機能性・効率性が高い。 <(3)の短所>ルール・クライアント側で、ルール・セットを複数回呼び出す必要があるため、ネットワー

ク遅延により効率性が低い。またルール・クライアント側で、複数のルール・セットを統合する必要が

あるため、機能性が低い。影響

派生要件保守性を高めるため、異なるルール・サービスで共通のコンポーネントを利用出来るように、ルール・

プロジェクトの構造化を検討する必要がある。関連 AD

参考資料ルール・ベースの意思決定サービスをルール・セットにマッピング http://www.ibm.com/developerworks/jp/websphere/library/ilog/brms_rulesets/

ルール・セット・パラメーターの方向ルール・クライアントからルール・セットを呼出す際には、ルール・セット・パラメーターによってデータの受け渡しを行

う。ルール・セット・パラメーターでは、入出力の方向を設定する必要がある。例えば、以下のようなインターフェースの要件があるとする。

図 3-1-2 ルール・セット・パラメーターの方向

この要件を満たすルール・セット・パラメーターの設定は、以下の 3 つの候補が考えられる。それぞれの候補につい

て、使用性、機能性、開発生産性の観点で比較する必要がある。 (1) 入力、出力、入出力を使用（要件により使い分け） (2) 入力、入出力を使用（出力を使用しない） (3) 入出力を使用（入力、出力を使用しない）

ルール・クライアントルール・サービス

ルール・セット呼出【入力要件】A, B

【出力要件】B, C

<インターフェース要件の例>

対象分野ルール・セット・パラメータートピック設計タイトルルール・セット・パラメーターの方向 Id. AD-ODM-0312 説明ルール・セット・パラメーターの方向についての設計方針を決定する。前提方向は、3 種類（入力、出力、入出力）ある。制約方向が出力の場合、初期化が必要。要件

基準 (A) 使用性 (B) 機能性 (C) 開発生産性

http://www.ibm.com/developerworks/jp/websphere/library/ilog/brms_rulesets/


- 12 -

ルール・セット実行前のデータ準備ルール・セットを実行するにあたり、データの準備が必要な場合がある。データの準備の例としては、ルール・クライア

ントとルール・セットのデータ構造が異なる場合にデータ構造を変換するか、ルール・セットの実行に必要なデータを

ルール・クライアントが保持していない場合に DB 等からデータを取得するなどである。データを準備するには、以下の 3 つの実現候補が考えられる。候補(1)は、ルール・クライアントでデータ準備をしてから、ルール・セットを呼出す場合である。候補(2)は、ルール・セ

ットの前に、ルール・セットをラップする統合サービスを置いて、そこでデータ準備をする場合である。物理的には、ル

ール・クライアントからリモート呼出しをするのに対して、統合サービスからはローカル呼出しをする想定である。候補

(3)は、ルール・セット内において、Java XOM 等でデータ準備をする場合である。それぞれの候補について、機能性、

保守性、開発生産性の観点で比較する必要がある。

候補

(1) 入力、出力、入出力を使用（要件により使い分け） <長所>ルール・クライアントにとって、入力パラメータ（入力、出力、入出力）と出力パラメータ（出力）

が明確になり、使用性が高い。また、出力パラメーターの初期値設定をカスタマイズ出来るため、機

能性が高い。 <短所>出力パラメーターの初期化が必要なため、開発生産性が低い。 (2) 入力、入出力を使用（出力を使用しない） <長所>出力パラメーターの初期化が不要なため、開発生産性が高い。 <短所>ルール・クライアントにとって、入力パラメーター（入力、出力、入出力）が不明確になり、使用

性が若干低い。出力パラメーターの初期値設定をカスタマイズ出来ないため、機能性が低い。 (3) 入出力を使用（入力、出力を使用しない） <長所>出力パラメーターの初期化が不要なため、開発生産性が高い。 <短所>ルール・クライアントにとって、入力パラメーター(入出力）と出力パラメーター（入出力）が不

明確になり、使用性が低い。出力パラメーターの初期値設定をカスタマイズ出来ないため、機能性が

低い。決定 (1)または(2) ※プロジェクト毎に記載してください。決定理由 ※プロジェクト毎に記載してください。影響派生要件関連 AD 参考資料


- 13 -

図 3-1-3 ルール・セット実行前のデータの準備

対象分野ルール・セットトピック設計タイトルルール実行前のデータ準備 Id. AD-ODM-0313

説明ルール・クライアントとルール・セットのデータ構造が異なる場合に、ルール実行前にデータ準備（変

換・取得など）を実現する箇所を決定する。前提制約ルール・セット内でデータ準備することは、製品の標準機能にはない。

要件ルール・クライアントが要求するデータ構造と、ルール・セットが要求するデータ構造が異なる場合が

多いため、設計方針を決定することが重要である。

基準 (A) 機能性 (B) 保守性 (C) 開発生産性

候補

(1)ルール・クライアント <長所>ルール・セットでのデータ準備が不要なため、ルール・クライアントのデータ構造の変更がル

ール・セットにも影響せず、保守性が高い。また、ルール・クライアントでのデータ準備の方が、開発

生産性が高い。 <短所>ルール・クライアントにおいて、ルール・セットのデータ構造を意識したデータ準備が必要な

ため、ルール・クライアントにとってのルール・セットの機能性が低い。 (2)統合サービス <長所>ルール・クライアントでのデータ準備が不要なため、機能性が高い。また、ルール・セットでの

データ準備が不要なため、ルール・クライアントのデータ構造の変更がルール・セットにも影響せず、

保守性が高い。 <短所>ルール・クライアントへの公開の方式によっては、統合サービスの開発が困難で、開発生産

性が低い場合がある。 (3)ルール・セット <長所>ルール・クライアントでのデータ準備が不要なため、機能性が高い。

ルール・クライアントルール・セット

データ準備

ルール・クライアント統合サービス

ルール・セット呼出

ルール・クライアントルール・セット

データ準備


ルール・セット

データ準備


(1) ルール・クライアント

(2) 統合サービス

(3) ルール・セット

※リモート呼出

※ローカル呼出


- 14 -

<短所>ルール・セットにおいて、ルール・クライアントのデータ構造を意識したデータ準備が必要な

ため、ルール・クライアントのデータ構造の変更がルール・セットにも影響してしまい、ルール・セット

の保守性が低い。決定 (1)または(2) ※プロジェクト毎に記載してください。決定理由 ※プロジェクト毎に記載してください。影響派生要件関連 AD 参考資料


- 15 -

構造化プロジェクトの構造化をおこなう業務的な動機としては、部門間で共有したいルール・パッケージと各業務部門ごとに

所有したいルール・パッケージについて、権限を分けて管理する場合が考えられる。様々な業務で共通して用いられ

るルール／語彙について、コピーして各ルール・セットに取り込むするようなことは、管理の面でも効率の面でも避けた

い。そのような場合には、共通の作成物を収めるプロジェクトと、業務固有の作成物を収めるプロジェクトを分割し、固

有のプロジェクトから共通プロジェクトを参照するべきである。また、分割と参照を適切に設計することは、開発効率の

面でも良い影響がある。構造化をせずに無関係な他業務のルールが大量にスコープに含まれれば、開発中に変数

やメソッドを選びにくくなる上、ビルド時間やリソースも余分にかかってしまう。

プロジェクトの分割 ODM で設計・開発する各アーティファクト（ルール・フローやビジネス・ルールや BOM など）は、複数のルール・プロジ

ェクトに分割して、参照することが可能である。例えば、図のように、ルール・フローとビジネス・ルールと BOM を別々

のルール・プロジェクトに分割して、ルール・フローを含むプロジェクトからビジネス・ルールを含むプロジェクトを参照

し、ビジネス・ルールを含むプロジェクトから BOM を含むプロジェクトを参照すれば、1 つのルール・セットとして実行が

可能になる。

図 3-2-1 プロジェクトの分割

意思決定サービスにおけるルール・セットの入出力の変数は、意思決定操作のシグニチャーとしてメイン・プロジェクト

に定義する。メイン・プロジェクト内、または、メイン・プロジェクトから参照可能な従属プロジェクト内で定義されたルー

ル・セット変数が、このシグニチャーとして使用可能である。また、ルール・セット変数は、ビジネス・ルールを記述するために、ビジネス・ルールを含むプロジェクトのスコープ内に

設定されている必要がある。例えば、図の例で、ルール・セット変数 Z を異なるプロジェクトに設定した場合を考える。

ルール・フローを含むプロジェクトに設定した場合は、ビジネス・ルールを記述することが出来ない。BOM を含むプロ

ジェクトに設定した場合は、ルール・セット変数が参照している親に引き継がれることで、ビジネス・ルールを記述するこ

とが出来る。 ※参考： IBM Knowledge Center - プロジェクト階層の設定 http://www.ibm.com/support/knowledgecenter/ja/SSQP76_8.8.0/com.ibm.odm.dserver.rules.designer.dev/developing_topics/con_ds_dev_project_org.html IBM Knowledge Center - ルール・セットの内容とシグニチャーの定義 http://www.ibm.com/support/knowledgecenter/ja/SSQP76_8.8.0/com.ibm.odm.dserver.rules.designer.dev/rulesets_topics/con_ds_dev_operations.html

メイン・ルール・プロ

ジェクト

意思決定操作

ルール・フロ

ー

入出力定義

ルール・プロジェクト

BOM

クラスＺ

Java プロジェクト

XOM

class Z


ルール

パッケージＡ

パッケージＢ

ルール・セット変数Ｚ

http://www.ibm.com/support/knowledgecenter/ja/SSQP76_8.8.0/com.ibm.odm.dserver.rules.designer.dev/developing_topics/con_ds_dev_project_org.html

http://www.ibm.com/support/knowledgecenter/ja/SSQP76_8.8.0/com.ibm.odm.dserver.rules.designer.dev/developing_topics/con_ds_dev_project_org.html

http://www.ibm.com/support/knowledgecenter/ja/SSQP76_8.8.0/com.ibm.odm.dserver.rules.designer.dev/rulesets_topics/con_ds_dev_operations.html

http://www.ibm.com/support/knowledgecenter/ja/SSQP76_8.8.0/com.ibm.odm.dserver.rules.designer.dev/rulesets_topics/con_ds_dev_operations.html


- 16 -

プロジェクトの共有ここでは、いつくかのケースを想定して、プロジェクトの分割と共有による構造化を検討する例を解説する。プロジェクトの構造化を検討する動機として、複数のルール・セットにまたがって同一のアーティファクトが重複している

場合に、それらを共有・統合したいということが上げられる。そこで、以下の 3 つのケースについて検討する。

ケース

共有するアーティファクト

用例

フロールールＢＯＭＸＯＭ

Ａ ○ ○

• 全社で利用される語彙を共有する • ユーティリティーの処理を共有する

Ｂ ○ ○ ○

• 部門間で同一のチェック処理のロジックを

共有する

Ｃ ○ ○ ○ ○

• 部門間で同一の、分類と集計など順序の

ある処理を共有する

ケースＡ: BOM と XOM の共有全社や業務間で共通して使われる語彙については、共通 BOM プロジェクトとそれに対応する XOM のプロジェクトを

作成し、定義を共有すべきである。また、特定業務と密接に関係していない一般的な処理（日付計算、四捨五入など）

をユーティリティー用のプロジェクトとして共有する場合、やはりこの参照のパターンとなる。共通化により、開発生産

性、保守性の向上が見込まれる。ケースＢ: ルール、BOM、XOM の共有ルール・セット間で共通の業務処理が存在する場合、共通ルール用のパッケージとプロジェクトを作成することを検討

しよう。法律や業界規範や社内の内規へ対応するための確認処理などは、このパターンで切り出せる可能性がある。ケースＣ: フロー、ルール、BOM、XOM の共有分類処理からの集計処理など、順序性のある処理が複数の業務に共通して含まれる場合、このケースにあたる。対象

の処理の間に他の処理が含まれず、独立している場合、サブ・フローとして切り出して共有することが可能である。


- 17 -

図 3-2-2 BOM と XOM を共有する場合の例

図 3-2-3 ルール、BOM、XOM を共有する場合の例

メイン・プロジェクト

意思決定操作

ルール・フロールール・プロジェクト

BOM

クラスＺ


XOM

class Z


ルール

パッケージＡ

パッケージＢ

ケース A の例


ルール

パッケージＣ

パッケージＤ


意思決定操作

ルール・フロー


BOM

クラスＹ


XOM

class Ｙ

共有されたプロジェクト


意思決定操作


BOM クラスＺ


XOM

class Z


ルールパッケージＡ

ケースＢの例


ルールパッケージＣ


意思決定操作



ルールパッケージＢ



- 18 -

図 3-2-4 フロー、ルール、BOM、XOM を共有する場合の例


意思決定操作


BOM クラスＺ


XOM

class Z


ルール

パッケージＡ

パッケージＢ

ケースＣの例


サブ・フローメイン・プロジェクト

意思決定操作


ルール

パッケージＣ



- 19 -

語彙語彙は、ビジネス・ルールを開発（編成）するときに使用される。BOM のクラスおよびメンバーを言語化すると、語彙と

して使用可能になる。

図 3-3-1 語彙の設定画面

ちなみに、BOM は、業務ユーザーが使用する Decision Center では変更できず、開発メンバーが使用する Rule Designer のみで変更できる。語彙は、ビジネス・ルールの基礎となる部分であるので、開発メンバーは、業務ユーザー

がビジネス・ルールを保守しやすいように、BOM を設計する必要がある。

BOM クラスの階層 BOM クラスは、データ・モデルの構造を反映させて、構造化することが出来る。構造化を検討する上では、以下の 2 つの候補が考えられる。候補(1)は、BOM の階層を深くした場合である。候補(2)は、BOM の階層を浅くした場合である。それぞれの候補について、保守性の観点で比較する必要がある。

図 3-3-2 階層の深い構造と浅い構造の BOM クラスの例

対象分野 BOM トピック設計タイトル BOM クラスの階層 Id. AD-ODM-0331 説明 BOM クラスの階層をどう設計するかによって、ビジネス・ルールの保守性が変わる。前提ビジネス・ルールは、BOM の語彙によって構成される。制約ビジネス・ルールの表現が、BOM のクラスの階層によって変わる。

<ビジネス・ルール> <BOM>

(1) 深い構造 (2) 浅い構造

金融

個人

借主

金融

個人

借主

名前

年齢

個人

名前

年齢

個人

破産暦

収入

金融

破産暦

収入

金融

BOMメンバー

BOMクラス

BOMメンバー

BOMクラス

融資

借主

契約

融資

借主

契約

期間

金額

融資

期間

金額

融資破産暦

収入

名前

年齢

借主

破産暦

収入

名前

年齢

借主

期間

金額

融資

期間

金額

融資

仮定条件‘契約’の’借主’の’個人’の年齢は 20以上である

<ビジネス・ルールの例>

仮定条件’借主’の年齢は 20以上である

<ビジネス・ルールの例>


- 20 -

要件ビジネス・ルールの保守性を上げたい。業務ユーザーがビジネス・ルールを保守する際に、BOM の

構造は管理対象外であるため、ビジネス・ルールの開発時に考慮しておく必要がある。基準 (A) 保守性

候補 (1) 深い構造 (2) 浅い構造

決定 (2) 浅い構造

決定理由

重視する基準：(A) 保守性 <(2)の長所>BOM クラスの階層が浅いと、ビジネス・ルールの可視性が高くなり、保守性が上がる。 <(1)の短所>BOM クラスの階層が深いと、ビジネス・ルールの記述が「”BOM クラス 1”の”BOM クラ

ス 2”の”BOM クラス 3”の…」となり、ビジネス・ルールの可視性が低くなり、保守性が下がる。（※変

数セットを使用することで、可視性を上げることは可能。）影響派生要件ルール・クライアントとの連携において、データ構造の差異が問題になる可能性がある。関連 AD AD-ODM-0313：ルール実行前のデータ準備参考資料

BOM と XOM の設計アプローチ BOM と XOM を設計するには、以下のように 2 つの設計アプローチ候補がある。候補(1)は、あるべき姿のデータ・モ

デルを設計してからルール開発を進める、トップダウン方式である。トップダウン方式では、ルール担当者がデータ・モ

デルを作成し、ルール開発で利用する。候補(2)は、クライアントシステムのデータ・モデルを利用し、ルール開発を進

める、ボトムアップ方式である。それぞれの候補について、機能性と開発生産性の観点で比較する必要がある。

図 3-3-3 BOM と XOM の設計アプローチ

対象分野 BOM と XOM トピック設計タイトル BOM と XOM の設計アプローチ Id. AD-ODM-0332 説明 BOM と XOM の設計アプローチを決定する。前提 BOM、XOM の設計アプローチを決定する際、機能性、開発生産性を考慮する必要がある。制約要件


- 21 -

基準 (A) 機能性 (B) 開発生産性

候補

(1) トップダウン方式 <長所>ルール担当者が業務要件からあるべき姿のデータ・モデルを設計し、ルール設計、開発を進

めることができ、機能性が高い。 <短所>ボトムアップと比較すると開発生産性が低い。 (2) ボトムアップ方式 <長所>クライアントシステムのデータ・モデルをそのまま利用する、またはルール用にカスタマイズし

て利用することができるため、開発生産性が高い。 <短所>クライアントシステムのデータ・モデルを利用した場合、あるべき姿のデータ・モデルになら

ず、機能性が低い。推奨アプローチは(1)トップダウン方式だが、クライアントシステムの要求、制約により(2)ボトムアップ

方式となる。(2)を採用する場合は、機能性を高めるため、データ準備の実現を検討する。「3-1-3 ルール・セット実行前のデータ準備」参照

決定 ※プロジェクト毎に記載してください。決定理由 ※プロジェクト毎に記載してください。影響派生要件関連 AD 3-1-3 ルール・セット実行前のデータ準備

参考資料 Top-down, Bottom-up https://www.ibm.com/developerworks/community/blogs/brms/entry/topdownbottomup?lang=en_us

XOM の開発言語 ODM では、XOM は、Java, XML, COBOL, .NET で開発することが出来る。ここでは、XOM の開発言語の候補とし

て、XML と Java を取り上げて検討する。 ※ODM V8.8.0 Knowledge Center：概要: BOM および実行オブジェクト・モデル (XOM) http://www.ibm.com/support/knowledgecenter/SSQP76_8.8.0/com.ibm.odm.dserver.rules.designer.author/designing_bom_topics/con_bom_overview.html XOM の開発言語の候補としては、(1) XML、(2) Java、(3) XML + Java が考えられる。それぞれの候補について、保

守性と効率性と機能性の観点で比較する必要がある。対象分野 XOM トピック設計タイトル XOM の開発言語 Id. AD-ODM-0333 説明 XOM の開発言語を決定する。前提制約ユーティリティーは、XML で開発出来ず、Java で開発する必要がある。要件

基準 (A) 保守性 (B) 効率性 (C) 機能性

候補

(1) XML <長所>データ構造の可読性が高く、素早く容易に変更できるため、保守性が高い。 <短所> Java と比較して、実行時のパフォーマンス（TPS）が 2 倍ほど遅く、効率性が低い。また、ユー

ティリティーを開発出来ないため、機能性が低い。

https://www.ibm.com/developerworks/community/blogs/brms/entry/topdownbottomup?lang=en_us

http://www.ibm.com/support/knowledgecenter/SSQP76_8.8.0/com.ibm.odm.dserver.rules.designer.author/designing_bom_topics/con_bom_overview.html

http://www.ibm.com/support/knowledgecenter/SSQP76_8.8.0/com.ibm.odm.dserver.rules.designer.author/designing_bom_topics/con_bom_overview.html


- 22 -

(2) Java <長所> XML と比較して、実行時のパフォーマンス（TPS）が 2 倍ほど速く、効率性が高い。また、ユ

ーティリティーを開発出来るため、機能性が高い。 <短所>データ構造の可読性が低いため、保守性が低い。 (3) XML（エンティティ） + Java（ユーティリティー） <長所>XML のデータ構造の可読性が高く、素早く容易に変更できるため、保守性が高い。また、ユ

ーティリティーを Java で開発出来るため、機能性が高い。 <短所> Java と比較して、実行時のパフォーマンス（TPS）が 2 倍ほど遅く、効率性が低い。

決定 ※プロジェクト毎に記載してください。決定理由 ※プロジェクト毎に記載してください。影響派生要件関連 AD 参考資料

拡張性を持たせたデータ構造設計サービスイン後に発生するの変更対応の可能性を検討し、変更対応の影響を最小限にとどめるためのデータ構造設

計方針を検討する。サービスイン後、変更が発生すること、また変更内容が予測できる場合は、事前に変更を見込ん

だカラムを定義しておくことで、影響を最小限にとどめた変更対応が可能となる。しかし、変更発生の可能、頻度は高いが、どのような変更が発生する予測がつかない場合は、キーバリューを用いた

データ構造設計を検討する。対象分野 XOM トピック設計タイトル拡張性を持たせたデータ構造設計 Id. AD-ODM-0334 説明変更発生時の拡張性を持ったデータ構造設計方針を定する。前提制約

要件サービスイン後、データ構造に変更が発生する可能性があり、変更の影響を最小限にとどめた対応

が可能となるデータ構造設計とすることが重要である。

基準 (A) 開発生産性 (B) 保守性

候補

(1) キーバリュー <長所>データ構造の構成要素の追加、変更、削除で対応ができ、データ構造そのものを変更する

必要がない <短所>実装が複雑となり、開発生産性、保守性が低下する

決定 ※プロジェクト毎に記載してください。

決定理由 ※プロジェクト毎に記載してください。影響派生要件変更発生時の対応手順の明確化関連 AD

参考資料 [Introducing the Generic Ruleset Signature pattern for WebSphere Operational Decision Management V7.5Part 1: A framework for achieving agility in rules projects] http://www.ibm.com/developerworks/websphere/bpmjournal/1202_crowther/1202_crowther.html

http://www.ibm.com/developerworks/websphere/bpmjournal/1202_crowther/1202_crowther.html


- 23 -

ドメイン

静的ドメインと動的ドメインドメインとは、BOM タイプ・エレメントの有効値を制約する機能である。BOM クラスやメンバー等にドメインを適用する

ことにより BOM を特化することができる。例えば、ビジネス・ルールの条件やアクションの定義でドメイン項目を使用し

て記述した場合、その値は、ユーザーが直接入力するのではなく作成済みの列挙値（“営業課長”、“監査部長”、“社

長”など）の一覧から選択して使用できるようになる。ドメインに指定できる BOM エレメントは、クラス、メンバー・タイプ、メソッド戻り型そして、メソッドの引数である。上記のように、ドメインを使用することでルール編集者の生産性、保守性を向上できる。また、ドメインを使用することで

予期しないデータが入力されるのを防ぐことができ、ビジネス・ルールの品質向上にも役立つ。

図 3-4-1 ドメイン機能による有効値の制約

ドメインの種類は、下図のとおり分類される。実プロジェクトでは、主に、ビジネス・ルールで使用できる列挙型ドメイン

（静的ドメインの一部と動的ドメイン）に関して考慮すれば十分である。

図 3-4-2 ドメインの種類

静的ドメインは、Rule Designer の BOM エディターを使って、数値型や文字列型データのセットを作成、保管する方式

である。したがって、値のセットを変更、追加、削除するには、BOM エディターでの編集作業が必須となる。一方、動的ドメインは、BOM の外部、つまり、Excel や DB でデータのセットを保管、管理する方式である。動的ドメインを使用する場合は、ドメイン項目値として提供される値のリストが動的に作成されるため BOM を手動で変

更する必要はない。静的ドメインと動的ドメインの作成方法は、後述の参考説明を参照のこと。


- 24 -

ユーザー部門においても Excel で管理（保守）できる動的ドメインの使用がお勧めである。また、IT 部門がルールを開

発・保守する場合でも動的ドメインの使用は、生産性・保守性が高くお勧めである。動的ドメインの保管場所に DB リソースを使った場合、例えば、既存の共通 DB マスターを使用すれば、ルール呼び

出しシステムとルール・エンジン側でドメイン項目値の整合性が担保されるという利点もある。動的ドメイン使用時の考慮点は、「BOM の更新」機能を実行した場合、タイプをドメイン型に手動で変更しなおす必要

がある。このため、動的ドメインの適用タイミングとしては、ルールが洗練され、ある程度実装が固まったあとに行うのが

お勧めである。対象分野ドメイントピックデータ設計タイトル静的ドメインと動的ドメイン ID AD-ODM0341

説明静的ドメイン、動的ドメインの使用によりビジネス・ルール開発の生産性、保守性が変わる前提ドメインは、BOM タイプ・エレメントの値を制約する制約・ドメイン項目値の変更度合い、項目数、および、保管場所（BOM 内部 or 外部データ）

・保守担当部門（LOB または IT 部門）

要件ルール開発、保守におけるドメイン項目値入力の生産性を上げたい。また、LOB が容易に保守できること

が重要である。基準 (A) 生産性 (B) 保守性

候補 (1) 静的ドメインを使用する (2) 動的ドメインを使用する

決定 (2) 動的ドメインを使用する決定理由重視する基準： (A)生産性、(B) 保守性

＜(1)の短所＞大量のドメイン項目値を生成・保守するには、動的ドメインより生産性・保守性が良くない。

また、BOM エディターによる静的ドメイン項目値を変更した場合は、XOM との手動同期が必要となる。＜(2)の長所＞Excel を使って容易にドメイン項目値を生成・保守できる。

影響 BOM 設計派生要件関連 AD 参考資料 ODM V8.8.0 Knowledge Center：ドメインの処理

http://www.ibm.com/support/knowledgecenter/SSQP76_8.8.0/com.ibm.odm.dserver.rules.designer.author/config_auth_topics/tpc_rd_bom_domains.html

参考：静的ドメインの作成例以下に、loanValidation サンプルを使用した静的ドメインの作成例を示す。 Report クラスの grade メンバーに対して静的ドメインを作成する。

(1) loan.Report クラスの grade メンバーを開くルール・エクスプローラーから BOM モデルの Report クラスを展開して grade メンバーをダブルクリックする。


- 25 -

図 3-4-3 ルール・エクスプローラー

(2) ドメインの作成 BOM エディターに grade メンバーが表示されたら、ドメイン・セクションにある「ドメインを作成する」リンクをクリックする。

図 3-4-4 BOM エディター（メンバーgrade）

(3) ドメイン型の選択静的ドメインとして「リテラル」を選択して[次へ]をクリックする。


- 26 -

図 3-4-5 ドメイン型

(4) 列挙子の定義 [追加]をクリックしてリテラル列挙子を定義する。

図 3-4-6 リテラル列挙子（例： A, B, C, D, E）

(5) ドメイン項目値 BOM エディターのドメイン・セクションに作成したドメイン項目値が表示される。


- 27 -

図 3-4-7 ドメイン型：リテラル

(6) 意思決定表における静的ドメインの使用例以下は、意思決定表のアクション値としてドメイン項目値を使用する例である。

図 3-4-8. 意思決定表における静的ドメインの使用例（等級）

(7) 静的ドメイン項目値の追加・削除静的ドメイン項目値を追加、削除するには BOM エディターから「ドメインを編集する」リンクをクリックして保守する。ドメイン自体を削除するには、「ドメインを削除する」リンクをクリックする。下記の例では、A,B,C,D,E のすべての値が一

度に削除される。


- 28 -

図 3-4-9 ドメインの保守

参考：動的ドメインの作成例以下に、loanValidation サンプルを使った動的ドメインの作成例を示す。 Loan クラスの approvalLevel メンバーに対して動的ドメインを作成する。

(1) approvalLovel メンバーの追加まず、事前準備として、XOM の Loan クラスに、String 型の“approvalLevel”メンバーを追加する。次に、BOM を更新

して Loan BOM クラスに approvalLevel メンバーを追加する。以降、approvalLevel メンバーに対して、Excel を通して値を動的に作成、変更する手順を示す。

図 3-4-10 approvalLevel メンバー追加

一度にすべて削除

＜XOM＞＜BOM＞


- 29 -

(2) 動的ドメイン用 Excel データの作成動的ドメインのデータは、Excel ファイルで作成して、loanvalidator-rule プロジェクトのリソース・フォルダーへコピーす

る。以下に、「承認レベル」シートに入力した例を示す。

図 3-4-11 動的ドメイン用の Excel データ

後述するドメインの作成ウィザードで、「値」列を MyDomain.DynD クラスのメンバーに、「BOM から XOM」列を BOMから XOM へのマッピング値、そして、「日本語のラベル」列を言語化のラベル値としてマッピングする。

(3) 動的ドメイン用の BOM エントリー作成下記のとおり、空の BOM エントリーを作成する。例：名前：ドメイン

図 3-4-12 BOM エントリー


- 30 -

(4) 動的ドメイン用のクラス作成下記のとおり、ドメイン BOM エントリーに、動的ドメイン用のクラスを新規に作成する。例：パッケージ名： MyDomain クラス名： DynD

図 3-4-13 動的ドメイン用の DynD クラス

(5) 動的ドメインの作成 BOM エディターを開いて、DynD クラスのドメイン・セクションより「ドメインを作成する」リンクをクリックする。

図 3-4-14 ドメイン・セクション


- 31 -

ドメイン作成のウィザードが開くので、ドメイン型に動的ドメインの Excel を選択して、[次へ]をクリックする。

図 3-4-15 ドメイン型の選択

下記のとおり、Excel ファイルで定義した各列をドメイン情報とマッピングする。

例： − Excel ファイル： SampleDD.xls − シート：承認レベル − ヘッダー付き表：指定する − 値列：値 − BOM から XOM への列：BOM から XOM − ラベル列：日本語のラベル − 注釈列：注釈（日本語）

図 3-4-16 Excel ファイル列のマッピング


- 32 -

カスタム・プロパティーは追加せず、[終了]をクリックする。

図 3-4-17 カスタム・プロパティーの追加

BOM エディターを開いて、DynD クラスにドメイン項目としてのメンバーが追加されたことを確認する。

図 3-4-18 クラス DynD

カスタム・プロパティーに、下記の 2 項目が自動で追加される。名前： domainProviderResource, 値： SampleDD.xls 名前： domainValueProviderName, 値： com.ibm.rules.domainProvider.msexcel2003 （Excel 2003 の場合）


- 33 -

図 3-4-19 クラス DynD のカスタム・プロパティー

BOM から XOM へのマッピング・セクションで、実行名に型を指定する。例：java.lang.String （Loan クラスの approvalLevel メンバーの String 型に一致させる）

図 3-4-20 BOM から XOM へのマッピング

(6) ドメインの適用 Loan クラスの approvalLevel メンバーに動的ドメインを適用する。下記のとおり、approvalLevel タイプの参照ボタンをクリックして、String 型から DynD 型に変更する。


- 34 -

図 3-4-21 ドメイン型の指定

(7) ビジネス・ルールで動的ドメインを使用する下記は、ドメイン型の承認レベル（approvalLevel）を使った意思決定表ルールの例である。承認レベルの値を一覧か

ら選択できるようになる。

図 3-4-22 意思決定表における動的ドメイン使用例

承認レベル・アクション列の定義は、次のとおり。例： '融資' の承認レベルを<DynD:承認レベル一覧>とする

(8) ドメイン項目値の保守以下に、ドメイン項目値を変更・追加する例を示す。 Execel ファイルを開き下記のとおりデータを修正する。 ① 変更例：値：ID10007, 日本語のラベル：社長 → 値：ID10007, 日本語のラベル：副社長


- 35 -

② 追加例：値：ID10008, 日本語のラベル：社長更新した Excel ファイルをルール・プロジェクトに保存する。SampleDD.xls をダブルクリックして開いた場合は、更新後

に保存をクリック。外部呼出しで Excel を起動して更新した場合は、Winodws エクスプローラーからファイルをドラッグ

＆ドロップで SampleDD.xls を上書きする。

図 3-4-23 Excel データの更新例

BOM エディターを開き、動的ドメイン・クラス（DynD）のドメイン・セクションから、「動的値と同期化する」をクリックして

Excel ファイルのデータを更新する。

図 3-4-24 ドメインの同期化

下記のとおり、同期化によりメンバーID10007 のラベルが変更される。また、メンバーID10008 が新規に追加される。


- 36 -

図 3-4-25 メンバーID10007 および ID10008

Hint&Tips

3-4-4-1 バーチャル属性を使った動的ドメインの適用 3-4-3 参考：動的ドメインの作成例では、Loan クラスの approvalLevel メンバーに対して動的ドメインを適用している。こ

の方法では、XOM の変更にともない、「BOM の更新」を実行するたびに approvalLevel メンバーのタイプが動的ドメイ

ン・タイプ（例：DynD クラス）から XOM クラスの型（例：java.lang.String）に戻ってしまう。これを回避するには、approvalLevel メンバーの別名としてバーチャル属性を作成し動的ドメインを適用する方法があ

る。以下に、その方法を示す。

(1) approvalLevel メンバーの別名を作成 Loan クラスの BOM エディターを開いて、メンバー・セクションから[新規]ボタンをクリックして別名メンバーを作成する。

図 3-4-26 BOM エディターのメンバー・セクション

新しいメンバー・ダイアログで、メンバーのタイプを指定して、名前、タイプを入力する。


- 37 -

例：メンバーのタイプ：属性名前：approvalLevel_d タイプ：MyDomain.DynD （動的ドメイン・クラスを指定）

図 3-4-27 新しいメンバー

(2) approvalLevel_d メンバーの言語化 approvalLevel_d メンバーのメンバーの言語化セクションから、「デフォルトの言語化を作成する」リンクをクリックする。

図 3-4-28 メンバーの言語化

「語句で使用されている主語を編集する」リンクをクリックして、主語をデフォルトの英語から日本語にする。例：

主語：承認レベル・ドメイン


- 38 -

図 3-4-29 メンバーの言語化の例

(3) Getter/Setter の記述 BOM から XOM へのマッピング・セクションを開いて、Getter/Setter を記述する。例：

Getter: return this.approvalLevel; Setter: this.approvalLevel = value;

図 3-4-30 BOM から XOM へのマッピング

(4) ビジネス・ルールで動的ドメインを使用する（バーチャル属性の例）別名として作成したバーチャル属性に対して動的ドメインをセットする。承認レベル・アクション列の定義は、次のとおり。例： '融資'の承認レベル・ドメインを<DynD:承認レベル一覧>とする


- 39 -

図 3-4-31 意思決定表における動的ドメイン使用例（バーチャル属性）


- 40 -

変数ルールにおいてその変数をどのように使いたいかによって、変数を設定する方法は異なってくる。下図に設定方法の

検討の概略を示す。

図 3-5-1 変数の設定方法の選択

ルール・セット変数ルール・プロジェクト内で有効な変数は、ルール・セット変数としてルール・フォルダ内に変数セットを作成し、変数を定

義する。ルール・セット変数には複数の変数を定義でき、各ルール・セット変数の定義項目としては名称・タイプ・言語

化・初期値がある。ルール内で使用するには言語化を設定する必要がある。

ルール･アプリケーションのインターフェー

スで受け渡しされるべき値か

同タイプの全オブジェクトを対象とした処

理を記述したいか

ルール･セット･パラメーターとして、

意思決定操作のシグニチャーを設

定（3-5-2）

自動変数の生成を設定（3-5-3-2）

ルール変数を設定（3-5-3-1）

ルール・タスク間で受け渡しする必要があ

るかルール･セット変数を設定（3-5-1）当てはまる

当てはまらない

当てはまる

ある値をルールの中で使いたい

当てはまる


- 41 -

図 3-5-2 ルール･セット変数の設定

ルール・セット変数を使用すると、ルール・フローのタスク間で共通してデータの書き込み・呼び出しをすることができ

る。そのため、ルール・フローの中でタスクを越えて受け渡す中間値が必要な場合に、利用することができる。ルール･

プロジェクト内でグローバルに参照する値となるため、ルール･セット変数の利用時にはルールの独立性に配慮する必

要がある。ルール・フローのテスト中にルール･セット変数の値が意図どおりに遷移しているかを確認したい場合は、デバッグ・ビ

ューの変数パースペクティブを利用することができる。

ルール・セット・パラメータールール･セット・パラメーターは、クライアントとルール・アプリケーションの間のインターフェースに定義する変数である。

ルール・セット変数として指定した変数のうち、クライアントとのやりとりが必要なものについて、入出力の方向を設定す

ることで使用可能となる。具体的には、クライアントからの要求メッセージで受け取るデータを「入力」、クライアントへの

応答メッセージで渡すデータを「出力」、要求応答の両方に含まれるデータを「入出力」として設定する。ルール・セッ

ト・パラメーターとして設定した変数の言語化は、ルール･セット全体でルール記述に使用することができる。

図 3-5-3 ルール･セット･パラメーターの設定


- 42 -

バインディングによる変数ワーキング・メモリー内のオブジェクトのタイプを指定してルール内の変数に割り当てることを、バインディグという。バインディングによる変数の使い方として、各ルール内で変数を紐付けるのか（ルール変数）、またはあるタイプについ

て全ルールで有効な紐付けを BOM で設定しておくのか（自動変数）、を考慮して設定方法を決める。

3-5-3-1 ルール変数あるルールの内部でのみ有効なローカルな変数をルール変数と言い、ルールの定義部で宣言する。ワーキング・メモリー内に複数存在する要素に対して「ある（変数）」の表現を使ってルール変数を設定すると、該当の

タイプの各インスタンスについてルールを評価させることができる。複数の変数のバインディングルールの定義部で複数の変数を設定し、処理時にワーキング・メモリー上にそれぞれのタイプについて複数インスタ

ンスが存在している場合、ルールの評価はそれぞれのタイプのインスタンスの総当りの組み合わせについて行われ

る。以下の例では２つのタイプについてそれぞれ２つのインスタンスがあり、４通りの評価が行なわれる。例）設定：ある乗用車を`車`とする。設定：ある利用者を`乗客`とする。 ※ワーキング・メモリー上には、乗用車タイプの「車１」「車２」、利用者タイプの「乗客１」「乗客２」が存在。 →評価対象は、「車１, 乗客１」「車１, 乗客 2」「車 2, 乗客１」「車 2, 乗客 2」となる。定義部の「ここで（where）」節により対象を制限した変数「ここで」節の使用により、条件に当てはまるオブジェクトを対象として処理を記述することができる。定義部で以下の設定をすることにより、このルールではゴールドのカテゴリーの顧客に`優良顧客`として言及できるよう

になる。このルールは、ゴールドのカテゴリーの各顧客について評価される。例）設定：ある顧客を’優良顧客’とするここで顧客のカテゴリーは”ゴールド”と同一である。リストの定義同タイプのオブジェクトの集合について変数を定義すると、該当のインスタンスがリストとなったコレクション・タイプの変

数として暗黙的に定義される。たとえば、定義部で以下のように設定することにより、このルールではゴールドのカテゴリーの顧客全てを対象とした`ゴールド顧客リスト`を参照して、カウントや繰り返しの処理などが可能になる。例 1）リスト型のオブジェクト内から条件にあった要素のみを取り出してリストにする場合「設定：`要求`の顧客リストの中のすべての顧客を`ゴールド顧客リスト`とするここで各顧客のカテゴリーは”ゴール

ド”と同一である。」例 2）自動変数を設定した型の全インスタンスから条件にあうインスタンスのみを取り出してリストにする場合「設定：すべての顧客を`ゴールド顧客リスト`とするここで各顧客のカテゴリーは”ゴールド”と同一である。」

定数の定義ルール内で使用する定数も、定義部で宣言できる。定数の値の変更時には、定義の値のみを書き換えればよい。例） 0.08 を`税率`とする。


- 43 -

3-5-3-2 自動変数自動変数を設定すると、ワーキング・メモリー内の該当のタイプに紐づく変数が自動生成され、全てのビジネス・ルー

ルから使用できる。自動変数を使用するには、BOM のクラスの言語化の設定で「自動変数の生成」を有効化する。たとえば、あるタイプについてワーキング･メモリー上に複数のインスタンスが存在することが想定され、それらに対して

頻繁にルールで言及したい場合には、自動変数を生成することで、ルールの記述を容易にすることができる。

図 3-5-4 自動変数の生成の設定


- 44 -

対象分野変数トピック設計タイトル変数の定義 Id. AD-ODM- 説明ルールで使用する変数の定義方法を決定する。前提ルールの記述に必要な変数は、ルール・セット内で定義してある必要がある。制約ルールの記述にあたって、変数をどのように呼び出すことになるか、明確であること。

要件・変数をルール･セット内の必要なところで参照できること。・クライアントへ必要なデータを応答できること・ルールの記述ができること

基準 (A) 変数を参照可能な範囲 (B) クライアントとの要求･応答に含まれる値 (C) あるタイプの全インスタンスに対して処理を記述する必要性

候補

(1) ルール･セット変数 (2) ルール･セット･パラメーター (3) 自動変数 (4) ルール変数

決定 ※変数毎に検討してください。

決定理由

※変数毎に検討してください。変数の種類参照の範囲クライントとの伝達ルール･セット変数ルール･セット全体なしルール･セット・パラメ

ータールール･セット全体あり

自動変数ルール･セット全体（変数による）ルール変数個別ルール内なし

影響ルール記述にあたってその変数を参照できる範囲、その変数で呼び出されるオブジェクトの範囲派生要件関連AD

参考資料

IBM Knowledge Center - ルール編成に使用可能な変数 http://www.ibm.com/support/knowledgecenter/ja/SSQP76_8.8.0/com.ibm.odm.dserver.rules.designer.author/authoring_topics/con_rul_variables.html developerWorks - ビジネス・ルール管理システム（BRMS）ビジネス・ルールの変数 http://www.ibm.com/developerworks/jp/websphere/library/ilog/brms_variables/

実行モードと繰り返し処理

実行モードルール・エンジンの実行モードの種類と選択指針について記述する。ルール・エンジンには、RetePlus、Sequencial、Fastpathの３種類の実行モードがある。ルールの実行条件が評価される

タイミングと順序は、タスクの実行モード設定によって異なる。また、実行モードは、ルール・アプリケーションのコンパイ

ル時と実行時のパフォーマンスに影響を与える。

(1) RetePlus 作業メモリー内のデータの更新に合わせて、実行するルールが変更されるべきであれば、RetePlus モードを採用す

る。RetePlus は、IBM ODM V8.5 までのデフォルトの実行モードである（V8.6 からのデフォルトは後述の Fastpath）。

http://www.ibm.com/support/knowledgecenter/ja/SSQP76_8.8.0/com.ibm.odm.dserver.rules.designer.author/authoring_topics/con_rul_variables.html

http://www.ibm.com/support/knowledgecenter/ja/SSQP76_8.8.0/com.ibm.odm.dserver.rules.designer.author/authoring_topics/con_rul_variables.html

http://www.ibm.com/developerworks/jp/websphere/library/ilog/brms_variables/


- 45 -

ルールの実行条件とデータの状態をもとに、実行するルール・インスタンスを決定することを、パターン･マッチング・プ

ロセスという（下図の①）。RetePlus モードでは、実行予定のルール･インスタンスをアジェンダと呼ばれるスタックに追

加し（下図②）、ルールの実行によって作業メモリーが変更されるたびに（下図③）、パターン･マッチングとアジェンダ

の更新を再度行なう（このプロセスを最適化して評価対象のルールと条件の数を少なくするために、Rete アルゴリズム

による推論が用いられている）。

図 3-6-1 RetePlus モードの動作

(2) Sequencial ルールの間に相互依存関係がなく、設定された順序でのみ実行されればよい場合は、Sequencial モードが使用でき

る。 Sequencial モードでは、個別のルールの実行条件とルール･セット･パラメーターの状態にもとづいたパターン･マッチ

ングが行なわれ（下図①）、条件に当てはまったルール・インスタンスは直ちに実行される（下図②）（作業メモリーとア

ジェンダの概念が無い）。ルールの実行条件の再評価は行なわれず、タスク内で設定された順序で順次にパターン･

マッチングと実行が行なわれていく。

図 3-6-2 Sequencial モードの動作


- 46 -

(3) Fastpath Sequencial モードと同様に、作業メモリー変更によるパターン・マッチングの再評価が不要な場合、Fastpath モードも使

用できる。 FastPath モードでは、（RetePlus と同様に）ルール同士の条件の関係も考慮しながらパターン･マッチングが行なわれ、

条件に当てはまったルール･インスタンスはアジェンダに追加される（下図①）。パターン･マッチング後にルールの処

理が実行される（下図②）。ルール実行後、作業メモリーが更新されてもパターン･マッチングの再評価は行なわれず

に終了する。作業メモリー内で演算処理を行なうことで実行速度を上げたい場合、作業メモリーを用いない Squencial でなく、 Fastpath (または RetePlus)を使用する。また、対象のオブジェクトが多数ある場合や意思決定表によるテストが多数あ

る場合には、Sequencial モードに比べて Fastpath モードでパフォーマンスが改善される可能性があるとされている。

図 3-6-3 Fastpath モードの動作


- 47 -

対象分野実行モードトピック設計タイトル実行モードの選択 Id. AD-ODM-0332 説明ルールの実行モードを決定する。前提タスクごとに適した実行モードを選択することで、パフォーマンスが改善できる。

制約適したモードを選択するには、ルールの実行条件に関する依存関係の有無や、ルール・アプリケー

ションのオブジェクト数が判明していること。要件

基準

(A) 機能性・作業メモリーの更新時に、ルールの実行条件を再評価する必要があるか。 (B) 効率性・作業メモリー内で処理を行なうことで、ルール実行の効率を上げる必要があるか。・意思決定表を多用するか。

候補 (1) RetePlus (2) Sequencial (3) Fastpath

決定 ※プロジェクト毎に記載してください。

決定理由

※プロジェクト毎に記載してください。 (1) RetePlus 作業メモリーの更新時に、ルールの実行条件を再評価する必要がある。 (2) Sequencial ルールの実行条件の再評価が不要で、作業メモリー内での処理も必要ない。 (3) Fastpath ルールの実行条件の再評価が不要で、作業メモリー内での処理は行ないたい。または、意思決定

表を多用する。影響派生要件関連AD

参考資料 IBM Knowledge Center - 実行モードの決定 http://www.ibm.com/support/knowledgecenter/SSQP76_8.8.0/com.ibm.odm.dserver.rules.designer.run/optimizing_topics/tpc_opt_choose_execmode.html

http://www.ibm.com/support/knowledgecenter/SSQP76_8.8.0/com.ibm.odm.dserver.rules.designer.run/optimizing_topics/tpc_opt_choose_execmode.html

http://www.ibm.com/support/knowledgecenter/SSQP76_8.8.0/com.ibm.odm.dserver.rules.designer.run/optimizing_topics/tpc_opt_choose_execmode.html


- 48 -

繰り返し処理ルール・アプリケーション内で配列処理を実現する方法には、3 つの候補がある。

3-6-2-1 ルール内部で繰り返しを記述する方法パラメーター･ナビゲーションを用いた方法では、階層関係（親子関係）がある入力データに対して、１つのルールの内

部で繰り返し処理を実行する。ルールの定義部でコレクションの変数を設定し、このコレクションの変数を対象に繰り

返し処理を実行させる。まず定義部にて、リスト型のメンバーについて「（リスト）の中のすべての（エレメント）」と「ここで（条件）」を組み合わせ

た記述で、処理対象のコレクション変数を設定する。アクション内容は、「（コレクション変数）の中の各（エレメント）：」以下に、繰り返させたいアクションを記述する。

図 3-6-4 パラメーター・ナビゲーションによる繰り返し処理

図 3-6-5 パラメーター・ナビゲーションによる繰り返し処理のルールの記述例

この方法では、各ルールの定義部でコレクションを作成しているため、他の設定は特に不要である。そのため、該当の

ルールのみを見れば、このルールが実行している内容が理解できる。また、クラス構造を維持して処理を行なっている

ため、親クラスのインスタンスの要素を参照する処理などを書くことができる。たとえば、リストの子要素で一定の条件に

当てはまるものを集計し、その結果をを親クラスのフィールドに納めるような処理に利用可能である。

（ルールの定義部）設定: '要求' の顧客リストの中のすべての顧客を '東京都民リスト' とするここで各顧客の住所は文字列 "東京都" を含む。

東京都民リスト（コレクション）・顧客 A ・顧客 B

「顧客」クラス・氏名（文字列）・住所（文字列）

「要求」クラス・顧客リスト（「顧客」ク

ラスの List）・東京都民の数

BOM

要求インスタンス・顧客リスト

顧客Ａインスタンス・山田太郎・東京都

顧客 B インスタンス・鈴木花子・東京都

顧客Ｃインスタンス・佐藤一郎・千葉県

入力データ

紐付き有


- 49 -

一方で、同じパターン・マッチを多数のルールで使用する場合には、同内容の定義部が多数のルールに記述されるこ

とになり、保守性が低下する可能性がある。参考： Iterating over Input Parameters - Pattern matching using parameter navigation (英語) http://www.ibm.com/developerworks/mydeveloperworks/blogs/brms/entry/iterating_over_input_parameters_pattern_matching_using_parameter_navigation?lang=en_us 参考： Knowledge Center - ビジネス用語のリスト用のルール・アクション http://www.ibm.com/support/knowledgecenter/ja/SSQP76_8.8.0/com.ibm.odm.dserver.rules.designer.author/shared_actionrules_topics/con_actionrules_actions_lists.html

3-6-2-2 作業メモリーを用いた方法作業メモリーを用いた方法では、ルール・エンジンの仕組みを用いて、繰り返し対象のタイプの各インスタンスについ

て、そのルールを実行させることができる。この方法を利用するには、ルールが実行される前に作業メモリー上に対象

のタイプを読み込んでおき、ルール変数または自動変数を使ってルールを記述する。

図 3-6-6 作業メモリーによる繰り返し処理

作業メモリー上

（タスクの初期アクション等で作業メモリへの

insert を実施） for (int n=0; n < request.custmerList.size(); n++) {

insert (Custmer)request.custmerList.get(n);

}

「設定：ある顧客～」によるルール変数

入力データ








BOM

顧客A

顧客 B

顧客 C

「顧客」の自動変数

http://www.ibm.com/developerworks/mydeveloperworks/blogs/brms/entry/iterating_over_input_parameters_pattern_matching_using_parameter_navigation?lang=en_us

http://www.ibm.com/developerworks/mydeveloperworks/blogs/brms/entry/iterating_over_input_parameters_pattern_matching_using_parameter_navigation?lang=en_us

http://www.ibm.com/support/knowledgecenter/ja/SSQP76_8.8.0/com.ibm.odm.dserver.rules.designer.author/shared_actionrules_topics/con_actionrules_actions_lists.html

http://www.ibm.com/support/knowledgecenter/ja/SSQP76_8.8.0/com.ibm.odm.dserver.rules.designer.author/shared_actionrules_topics/con_actionrules_actions_lists.html


- 50 -

（１）ルール変数を利用した繰り返し処理の記述ルールの定義部でルール変数を宣言する際に「ある（オブジェクト）」という記述を利用することで、該当のオブジェ

クトの各インスタンスに対してルールが実行される（3-5-3-1 節「ルール変数」を参照）。この方法では、各ルールの定

義部にルール変数を宣言することで、自動変数の設定（後述）を行なわずに、繰り返し処理に対応する。繰り返させ

るべきルールが数個に限られている場合には、この方法では自動変数を設定しないでよい分、メリットがある。

図 3-6-7 ルール変数を利用した繰り返し処理のルールの記述例

（２）自動変数を利用した繰り返し処理の記述この方法では、特定のタイプのインスタンスを対象とした繰り返し処理のルールを、最も簡潔に記述することができ

る。繰り返させるべきルールの数が多い場合は、各ルールで変数を宣言するよりも、自動変数を利用するほうが各

ルールの記述を簡潔にすることができる。ただし、この方法を用いるためには、（１）自動変数の設定、（２）作業メモリ

ーへのデータの insert、の２箇所の設定が必要となる。

図 3-6-8 作業メモリーによる繰り返し処理のルールの記述例

作業メモリーを用いた方法は、元々の入力データのクラス構造と関わり無く、対象とするクラスのオブジェクトに対して

一様に処理を行ないたい場合に有効である。たとえば、あるタイプのデータのリストの子要素それぞれに対して、正常

な値が入っているか、特定の値が含まれていない（いる）か、などの一律の検査を行なう場合に特に適している。一方で、この方法では特定のクラスのみを作業メモリーに読み込んでいるため、元のデータのクラス構造を利用して処

理を行なうことが難しい。また、BOM での自動変数の設定や、作業メモリーへのデータの insert など、複数の箇所に

設定を施しておく必要がある。参考： Iterating over Input Parameters - Pattern matching against working memory （英語） https://www.ibm.com/developerworks/mydeveloperworks/blogs/brms/entry/iterating_over_input_parameters_pattern_matching_against_working_memory?lang=en_us

https://www.ibm.com/developerworks/mydeveloperworks/blogs/brms/entry/iterating_over_input_parameters_pattern_matching_against_working_memory?lang=en_us

https://www.ibm.com/developerworks/mydeveloperworks/blogs/brms/entry/iterating_over_input_parameters_pattern_matching_against_working_memory?lang=en_us


- 51 -

3-6-2-3 ルール・フローを用いた方法ルール･フローを用いた方法では、ルール・フローのタスクを単位として処理を繰り返す。タスク間の遷移条件にカウン

ターのテストなどの終了条件を設定し、条件に当てはまるまではタスクを繰り返し実行する。この方法を使うには、３箇所の設定を行なう。１つ目に、カウンターとなる変数と処理対象のタイプの変数をルール・セ

ット変数として用意する。２つ目に、繰り返しを行なうタスクの初期アクションで、カウンターの番号を利用して、リストの

要素を１つずつ、処理対象の変数に代入する。３つ目に、タスクの最終アクションで、カウンターを増分する。リスト内の

各要素について、このタスク内のルールを実行させることができる。設定箇所が多くなり、実行パフォーマンスもよくない為、単純な繰り返し処理のためにこの方法を利用することは推奨

されない。適用ケースとしては、例えば複数のルールについてまとめて繰り返しの終了条件を評価する必要があり、な

おかつその条件が各ルールの中では記述不可能である場合などに回避策として利用する（ただし、そのような状況で

は、ルール間の依存性が高くなってしまっていると考えられる。本来は各ルールが依存しあわないような設計にできる

ことが望ましい）。

図 3-6-9 ルール・フローによる繰り返し処理

‘処理中の顧客’ ・山田太郎・東京都

（タスクの初期アクションで対象の顧客を代入）

（ルール・セット変数を用意）・’カウンター’ ・’処理中の顧客’

（タスクの最終アクションでカウンターを増分）

タスクのループ

入力データ








BOM


- 52 -

図 3-6-10 繰り返し処理を行なうルール・フローの設定例

図 3-6-11 ルール・フローによる繰り返し処理のルールの記述例

この方法では、個別のルール内では繰り返しを意識せずに記述を行なうことができる。また、タスク単位での繰り返し

処理になるため、複数の一連のルールをまとめて１単位として繰り返させることができる。また、繰り返し処理が行なわ

れていることが、ルール・フローで明示されている。一方で、ループの制御のためにルール・セット変数を各２つ必要となり、本来の業務処理に不要な変数を追加で作成

しなくてはならない。上記の変数に加えて、タスクの初期アクションと最終アクションへも設定が必要である（図中で例

示したルール・プロジェクトでは、初期アクションの為のメソッドの作成と言語化も行なっている）。結果、繰り返し処理を

行なうための設定箇所は複数の箇所に分散し、見えにくくなっている。また、一般に、他の２つの方法に比べると処理

のパフォーマンスの面でやや劣っているとされている。


- 53 -

上述のようなデメリットがあるため、この方法の利用に当たってはよく検討を行い、特にこの方法でしか実装できない要

件がある場合に採用すべきである。たとえば、複数のルールをまとめて１単位として繰り返す必要があり、さらに繰り返

しの終了条件が各ルール内では記述しにくいようなものである場合などが考えられる。参考： Iterating over Input Input Parameters - Ruleflow (英語) https://www.ibm.com/developerworks/mydeveloperworks/blogs/brms/entry/iterating_over_input_input_parameters_ruleflow?lang=en_us 対象分野配列トピック設計タイトル配列処理の実現方法 Id. AD-ODM-0332 説明配列処理の実現方法を決定する。前提制約要件ルール・クライアントから配列のデータが渡されることがある。

基準

(A) 保守性・処理構造の明快さ

・ループの各回の実行制御をどの単位（ルール条件文、タイプ、タスク）で記述できるか (B) 機能性

・処理実施のための別途の設定の有無・データの階層性・関連性の維持の可能性

(C) 効率性・処理効率の良さ

候補

(1) パラメーター・ナビゲーション <長所>ループ処理のための変数が不要であり、機能性が高い。データ・タイプの階層を維持し

た処理が可能である。また、ループ処理がルール・エンジンに任せられるので、実行時のパフォ

ーマンスが良く、効率性が高い。 <短所>ループ処理が必要なルールが大量にある場合は、それぞれのルールでループ処理を

記述する必要があり、保守性が低い。 (2) 作業メモリー

<長所>ビジネス・ルールで配列を意識した記述をする必要がないため、保守性が高い。ルー

ル・エンジンにおけるパターン・マッチングで実現されるので、実行時のパフォーマンスが良く、

効率が高い。 <短所>ループ処理のために、作業メモリーへのデータのコピー処理や、自動変数の設定などが

必要であり、機能性が低い。データを取り出して作業メモリーにコピーするため、データのクラス

構造に戻った処理が行いにくい。また、ルール・エンジンの動作について深い理解が必要であ

る。 (3) ルール・フロー

<長所>ループ処理が明示的で可視性が高く、保守性が高い。タスク単位で実行有無を制御し

て処理を行なうことができる。 <短所>ループ処理のための変数が2つ必要であり、本来不要な変数の定義が必要なため、機

能性が低い。また、実行時のパフォーマンスが悪く、効率性が低い。決定 ※プロジェクト毎に記載してください。決定理由 ※プロジェクト毎に記載してください。影響派生要件関連AD

参考資料 Iterating over Input Parameters https://www.ibm.com/developerworks/mydeveloperworks/blogs/brms/entry/iterating_over_input_parameters?lang=en_us

https://www.ibm.com/developerworks/mydeveloperworks/blogs/brms/entry/iterating_over_input_input_parameters_ruleflow?lang=en_us

https://www.ibm.com/developerworks/mydeveloperworks/blogs/brms/entry/iterating_over_input_input_parameters_ruleflow?lang=en_us

https://www.ibm.com/developerworks/mydeveloperworks/blogs/brms/entry/iterating_over_input_parameters?lang=en_us

https://www.ibm.com/developerworks/mydeveloperworks/blogs/brms/entry/iterating_over_input_parameters?lang=en_us


- 54 -

エラー処理 ODM におけるエラーの発生および対応は、下表のとおりである。ただし、入力データの不具合によるエラーについて

は、より前工程で処理するのがベスト・プラクティスである。ルール・クライアント側で処理する方が、ルール開発の生産

性・保守性は良くなる。実際、どこでエラー処理に対応するかは、プロジェクトのアプリケーション要件に依存する。発生対応発生場所発生種類発生理由対応場所対応方針ルール・サービス外通信エラー、システム・

エラーなどインフラなどの

不具合ルール・クライアント ※ルール・クライアント側の方針

に従うルール・サービス内（ビジネス・ルール）

Null ポインター例外、

ゼロ除算例外など入力データの

不具合初期アクション入力データのバリデーションをし

て、メッセージに詰める XOM 内（Java メソッド）

Java 例外 Utility の品質 XOM 起こりえるエラーをキャッチして、

メッセージに詰める

図 3-7-1 エラーの発生と対応

NPE 本節では、ODM 側でエラー処理をする場合における Null Pointer Excepton（NPE）の回避方法について説明する。

NPE 以外のエラーは、本項の Hint&Tips を参照のこと。 ODM で使われるオブジェクトには、ルール・サービスを呼び出すクライアント・アプリケーションと連携する入出力パラ

メーター、および、作業メモリーに挿入されるオブジェクトがある。ルール開発者は、int や float のような Java プリミティ

ブ型を除いてこれらのオブジェクトの値が NULL であるかどうかをチェックしなければならない。例えば、入出力パラメーターで NULL チェックをしない場合、NULL が含まれていると、ルール・サービスの呼び出し

時に NPE が発生する。また、ルールの実行時にある語彙の値に NULL が含まれていると、ルール実行時に NPE が

発生して処理が停止する。 NULL チェックの対象となるのは、以下のタイプの属性やメソッド戻り値となる。

− Java wrapper type (例、java.lang.Integer, java.lang.BigDecimal.等) − java.lang.String − カスタム・タイプ

ルール・サービス

（ビジネス・ルール）

XOM

（Javaメソッド）ルール・クライアント

図 3-7-2 エラー発生場所の種類


- 55 -

以下に、本節で取り扱うエラーの対象範囲を示す。

NPEに対処するときに考慮すべきことは、NULL値の概念が技術的な概念であるため、業務ユーザーによるルール上

での NULL チェックは特別な要件がないかぎりお勧めしない。つまり、ルール作成者には NULL チェックの責務を課すべきではない。ルール実行中に NPE が発生しないように、ア

プリケーション開発者が NULL 値の混入を事前に防ぐようにすべきである。あるいは、ルール開発者が後述の NPE 対

処方法にて NULL チェックを実施すべきである。 NULL チェックのタイミングは、下記の２つがある。

① ルールが実行される前に NULL チェックする方法は、次のとおりである。

・3-7-1-1 ルール・フローの初期アクション・3-7-1-5 ルール・セット・パラメーターのデフォルト値

② ルールが実行中に NULL チェックする方法は、次のとおりである。

・3-7-1-2 BOM クラスのテスター・3-7-1-3 オペレーターの再定義・3-7-1-4 getter およびメソッドの再定義・3-7-1-6 "ヌルである"、"ヌルでない"の使用

以降の各節で、NPE 対処法の具体例を示す。

エラーの分類

通信エラー

入出力データエラー

システムエラー(H/W, S/W)

ルールでエラー処理(BAL)

アプリケーションエラー

BOMレベルでエラー処理

XOMレベルでエラー処理

クライアント・アプリでエラー処理

ルール・プロジェクトレベルでエラー処理

本章で扱う対象範囲

エラーの分類

通信エラー

入出力データエラー

システムエラー(H/W, S/W)

ルールでエラー処理(BAL)

アプリケーションエラー

BOMレベルでエラー処理

XOMレベルでエラー処理

クライアント・アプリでエラー処理

ルール・プロジェクトレベルでエラー処理

本章で扱う対象範囲

図 3-7-3 エラーの分類


- 56 -

3-7-1-1 ルール・フローの初期アクション本項のアプローチは、ルールが実行される前に NULL チェックを行う方法である。ルール・フローの初期アクションは、開始ノードを選択してプロパティー・ビューからアクセスする。NPE チェックの記述

方法は、IRL コードで直接記述するか、ルール・セット関数を定義して初期アクションから呼び出す方法がある。本項の例では、属性やパラメーター自体の NULL チェックをして、NULL の場合、初期値（” ”）をセットしている（対処

方法１）。また、NULLの場合、inputValid フラグに false をセットしてルールが実行されないように制御している（対処方

法２）。 NULL チェックに使用するために、ルール・セット・パラメーターに対しては、ルール・セット・パラメーター名または

getParameterValue() API, 作業メモリーに現れるオブジェクトに対しては、getObjects() API を使う。 API の詳細は、下記の IlrContext API ドキュメントを参照のこと。 ※ODM V8.8.0 Knowledge Center：「IlrContext API」ドキュメント http://www.ibm.com/support/knowledgecenter/ja/SSQP76_8.8.0/com.ibm.odm.dserver.rules.ref.designer/html/api/html/ilog/rules/engine/IlrContext.html 以下に、ルール・フローの開始ノードで初期アクションを記述した例を示す。

図 2. ルール・フローの初期アクション

図 3-7-4 ルール・フローの初期アクション

http://www.ibm.com/support/knowledgecenter/ja/SSQP76_8.8.0/com.ibm.odm.dserver.rules.ref.designer/html/api/html/ilog/rules/engine/IlrContext.html

http://www.ibm.com/support/knowledgecenter/ja/SSQP76_8.8.0/com.ibm.odm.dserver.rules.ref.designer/html/api/html/ilog/rules/engine/IlrContext.html


- 57 -

以下に、作業メモリー・オブジェクトを取得する getWorKingMemoryObjects メンバーの例を示す。 BOM から XOM へのマッピングの本文に getObjects メソッドによる記述を書く。戻り値は java.lang.Object の配列とす

る。

また、NULL チェックの結果として、ルールを実行するかどうかの判断は、変数セットで定義した boolean 型の

inputValid フラグで行う。以下は、変数セットの例である。

図 3-7-6 inputValid 変数セット

図 3-7-5 getWorKingMemoryObjects メンバー


- 58 -

3-7-1-2 BOM クラスのテスター本項のアプローチは、ルールが実行中に NULL チェックを行う方法である。BOM クラスにテスター・メソッドを追加して

NULL チェックを行う。テスターは、オブジェクトがルール・インスタンスで実行するのに適格かどうかを判断して、その結果を true/false で返

す。テスターは、オブジェクトに NULL を含むものを除外するフィルターの役目をする。テスターは、作業メモリーに挿入されたオブジェクトに対して作用する。したがって、事前処理としてルール・フローの

初期アクションで作業メモリーへの挿入が必要となる。このとき、ルールでは、作業メモリーのオブジェクトに対して自動

変数を使ってバインドするのでパラメーターは言語化してはならない。以下に、テスターで NULL チェックを記述した例を示す。

図 3-7-7 BOM クラスのテスター


- 59 -

3-7-1-3 オペレーターの再定義本項のアプローチは、ルールが実行中に NULL チェックを行う方法である。ルール開発者が、Virtual BOM メソッドを

作成して数字や文字の基本オペレーターを再定義することで、操作対象の値に対する NULL チェックを組み込む。し

たがって、オペレーターの両比較項目に対してすべての数字オペレーターを再定義しなければならない。また、オペ

レーターの比較項目に対してすべての文字オペレーター（※）を再定義しなければならない。 ※「ヌルである／ヌルでない」、または、「の１つである／の１つでない」は除く以下に、オペレーターの再定義の例を示す。

図 3-7-8 Virual メンバーの BOM から XOM へのマッピング


- 60 -

3-7-1-4 getter およびメソッドの再定義本項のアプローチは、ルールが実行中に、NULL チェックを行う方法である。BOM クラス・メンバーの getter やメソッド

に対して、BOM から XOM へのマッピング（B2X）に NULL チェックを埋め込む。したがって、本項の方法は、言語化

した getter や戻り値のあるメソッドすべてに対して、B2X のコードを記述する必要がある。パラメーターであれ作業メモリーであれ、属性が読み込まれるたびに、ルールの条件、アクション等で毎回、NULLが” ”に置き換えられる。以下に、getter の再定義の例を示す。

図 3-7-9 B2X の Getter


- 61 -

3-7-1-5 ルール・セット・パラメーターのデフォルト値本項のアプローチは、ルールが実行する前に NULL チェックを行う方法である。ルール･セット・パラメーターを使用す

る場合、「デフォルト値」をセットしてパラメーター・オブジェクトに対する NPE を回避する。デフォルト値は、意思決定操作におけるシグニチャーの方向が入出力, 出力の際に有効である。また、出力方向の場

合、デフォルト値のセットは必須である。指定しない場合は、NPE が発生する。以下に、ルール・セット・パラメーターのデフォルト値をセットした例を示す。

3-7-1-6 “ヌルである”、“ヌルでない”の使用本項のアプローチは、ルールが実行中に NULL チェックを行う方法である。“ヌルである”、“ヌルでない”は、ODM に

標準で提供されている語彙であり、BAL で記述できる。以下に、“ヌルである”を使った例を示す。

図 3-7-10 ルール・セット・パラメーターのデフォルト値

図 3-7-11 アクション・ルール


- 62 -

ODM における NPE 処理は、ルール・クライアント側で処理することがベスト・プラクティスである。しかし、NPE 処理を

ルール・エンジン側で行う場合、当該事象はテクニカルな課題であるためルール作成者やルール開発者が BAL で記

述するよりも、ルール開発者がより下位層のレベルで対処すべきである。また、ルール呼び出し側のアプリケーション

にて NPE 処理の結果をどう連携するかは事前の検討が必要である。対象分野エラー処理トピックデータ設計タイトル NPE 対処方法 ID AD-ODM0361

説明 NPE 対処法をあげ、設計上のポイントを示す。前提・ルール・セット呼び出しやルール・セット実行中に発生しうる Null Pointer Exception(NPE)をルール･

プロジェクトレベル、BOM レベル、ルールで捕捉する。・ルールを呼び出すシステムとの入出力データに対する NPE が対象範囲

制約要件ルール・エンジン側で NPE に対処したい。結果に NULL が含まれる場合は、ブランク相当の値を呼

び出し側に返す。基準 (A) 有効性 (B) 生産性 (C) 保守性 (D) 可視性

候補 (1) ルール・フローの初期アクション (2) BOM クラスのテスター (3) オペレーターの再定義 (4) getter およびメソッドの再定義 (5) ルール・セット・パラメーターのデフォルト値 (6) “ヌルである”、“ヌルでない”の使用

決定 (1) ルール･フローの初期アクション決定理由重視する基準： (A) 有効性、(B) 生産性、(C) 保守性

＜(1)の長所＞初期アクションで一元管理でき、BOM クラスやメンバーごとに個別に対処する必要が

ないので生産性、保守性がよい。また、BOM クラスやメンバーに対して有効であり、かつ、ルールの

実行を分岐制御できる。＜(2)の短所＞テスターは、作業メモリーに挿入されたオブジェクトに対して使用するもので用途が

限定的である。また、BOM エディター内部の定義エリアを使うため生産性、保守性が低い。＜(3)の短所＞すべてのオペレーターを再定義しなければならない。また、BOM エディター内部の

定義エリアを使うため生産性、保守性が低い。オペレーターに限定的である。＜(4)の短所＞言語化した getter や戻り値のあるメソッドすべてに対して再定義しなければならない。

また、BOM エディター内部の定義エリアを使うため保守性が低い。BOM クラスのメンバーに限定的

である。＜(5)の短所＞入出力,方向に限定である。また、ダイアログ上の 1 行エリアで IRL 式を編集するので

使いにくい。＜(6)の短所＞ルールに業務ロジックとシステム・ロジックが混在する。一般にヌルは、プログラミング

上の概念であり、ビジネス・ユーザーが取り扱うには不適切である。該当するすべての語彙に対して

NULL チェックが必要となり生産性、保守性が低い影響派生要件関連 AD 参考資料 Technote# 1585612 「Check for null values in rules」

http://www-01.ibm.com/support/docview.wss?uid=swg21585612


- 63 -

Hint&Tips

3-7-2-1 実行されないルールの取り扱い IBM ODM におけるルール実行の基本的振る舞いは、ルール・サービス呼び出しシステムから渡された入力データと

定義済み条件項目値をマッチングさせて条件に合致したルールを実行することである。したがって、条件に合致する

入力データがなかった場合には、ルールは何も実行されない。つまり、ルールを呼び出したクライアント側には、結果

データとしてデフォルトの値がそのまま返されることになる。アプリケーション要件にも依存するが、ルールが実行されなかったという事実をクライアント側に伝達するためには、ル

ール・フローでタスクの後処理として、処理されるデータと処理されないデータを明示的に分岐させる条件判断を組み

込む必要がある。以下は、loanValidation サンプルの融資審査ルール・フローの例である。資格タスクと保険タスクの間に、「ローン承認」

を条件としてルールが実行されるパターンとルールが実行されないパターン（例は、それ以外の場合）を制御してい

る。

下記のとおり、資格タスクで実行される承認ルールで、承認すべき‘ローン申請’の等級を A,B,C に制限している。そし

て、D,C の等級は、‘ローン’は承認されず、それ以外の場合となり処理が終了する。このとき、却下された理由をメッセ

ージとして追加して呼び出しクライアントに通知している。

図 3-7-12 ルール･フロー

図 3-7-13 アクション・ルール


- 64 -

3-7-2-2 “その他”の使用法意思決定表の条件値として、“その他”の使用は、テストの複雑さを増加させる。また、テストケースの漏れを起こし易く

不具合のもととなるためお勧めしない。“その他”の値には、具体的な値で条件付けしたもの以外のすべてが含まれて

しまうことに注意すべきである。このため、想定外の値で条件に合致し期待した結果にならないことが発生する。下記の例では、破産点数を企業の信頼度に加算するルールで、最後の破産からの年数として、“その他”を使用して

いる。この場合、想定している 9 以上の値以外にも、例えば、-1, 2, 6 などの値で条件に合致してルールが実行されて

しまう。

“その他”を使用しない記述方法としては、下記のように、期待する具体的な値を条件値に指定することである。

下記のように区分にギャップがあっても、“その他”を使用するとエラーが消滅するため正しいと錯覚してしまうが、業務

ルールとしては、期待した結果とはならないので注意すること。

図 3-7-14 意思決定表ルール～その他～

図 3-7-15 意思決定表ルール

図 3-7-16 意思決定表ルール～区分ギャップ～


- 65 -

3-7-2-3 ゼロ除算ルールで除算演算を記述する場合には、ゼロ除算にならないように除数の値に注意する必要がある。バリデーション・

チェックは、ルール呼び出し側のアプリケーションで処理されるべきであるがもし、クライアント側で対応できない場合

やルールの実行過程で除数が 0 になる可能性が想定されるときは、ルール側でゼロ・チェックが必要となる。下記は、’借主’の年収が 0 であった場合のエラー例である。除算演算の例： ‘融資’の金額 * 100 / ‘借主’の年収 ‘融資’の金額： int 型、 ‘借主’の年収： int 型

もし、‘借主’の年収が 0 であった場合、ゼロ除算エラーが発生する。以下は、エラー出力の例である。 Caused by: ilog.rules.engine.IlrUserRuntimeException: ゼロ除算 at action part of rule '計算.返済負担率' at call to '融資審査#計算 rule task body' at call to '融資審査 flow task body' at call to 'execute'

図 3-7-17 アクション・ルール～除算演算～


- 66 -

したがって、ゼロ除算に対処するためには、除数のゼロ・チェックを除算処理の前に組み込む。以下に、仮定条件にゼロ･チェックを記述した例を示す。

また、被除数を dobule 型とした場合には、int 型とは実行時の振る舞いが異なる。ルールは実行されるが返済負担率

の結果は、例えば、2147483647%のような異常値となる。いずれにしても、除数に対するゼロ・チェックは必要である。

図 3-7-18 アクション・ルール～ゼロ･チェック～


- 67 -

ログ出力 ODM 上でのログ出力については、基盤要件およびアプリケーション要件を検討した上で決定する。ログ要件は BOMの実装に影響があるため、プロジェクト初期の段階で決定する必要がある。 ODM 上では必要がない限りアプリケーション・ログを出力するべきではない（例：呼び出し元でログ出力してもらう等を

推奨）が、アプリケーション・ログを出力する要件が発生した場合について、その選択肢を以下に提示する。

（※1） DWH は、ルール・セット実行のトレースをデータ・ベースに保管するため、取得するトレースの内容を加味し

て、DB 容量のサイジングをする必要がある。また、DWH はルール実行サーバー上で稼動するため、JVM 構成や

Java Heap サイズなども考慮に入れて基盤設計を行わなければいけない。加えて、トレースを取得することにより、ルー

ルのパフォーマンスにも影響が出るため注意が必要。DWH のパフォーマンス最適化についての詳細は、下記の

Performance Tuning ドキュメントを参照のこと。なお、DWH の詳細は、Knowledge Center の文書を参照のこと。 ①IBM Operational Decision Management V8.0 Performance Tuning Guide 「Chapter8. Decision Server Rules: Tuning Decision Warehouse」 http://www.redbooks.ibm.com/redpapers/pdfs/redp4899.pdf ②ODM V8.8.0 Knowledge Center ：デシジョン・ウェアハウス http://www.ibm.com/support/knowledgecenter/SSQP76_8.8.0/com.ibm.odm.dserver.rules.res.managing/topics/con_res_dw_overview.html

デバッグ用ツール（Log4Jなど）を使用する

<特徴>Java XOMの中でログを出力する場合に使用する。特定のコードに対して、debugコードなどを仕掛けて意図的にログを出力する。

APIを使用する

<特徴>ルール実行サーバーで提供されているAPIを利用してログを取得する。

DWH（デシジョン・ウェアハウス）を使用する

<特徴>製品機能であるDWHを利用して、特定のイベントまたは意思決定についてのトレース情報を取得する。（※1）

出力方法とその特徴

2

・debugコードなどを仕掛けて、流れているデータを取得

・ログフォーマットなど、柔軟なカスタマイズが可能

3

・実行詳細概要

- 意思決定 ID

- 日付

- 実行済みルール・セット・パス

- 処理時間

- 実行されたルールの数

- 実行されたタスクの数

・ルール・フロー・タスク・ツリーのある意思決定トレース

・入力パラメーター

・出力パラメーター

・実行の出力

1

ログ種類No

デバッグ用ツール（Log4Jなど）を使用する

<特徴>Java XOMの中でログを出力する場合に使用する。特定のコードに対して、debugコードなどを仕掛けて意図的にログを出力する。

APIを使用する

<特徴>ルール実行サーバーで提供されているAPIを利用してログを取得する。

DWH（デシジョン・ウェアハウス）を使用する

<特徴>製品機能であるDWHを利用して、特定のイベントまたは意思決定についてのトレース情報を取得する。（※1）

出力方法とその特徴

2

・debugコードなどを仕掛けて、流れているデータを取得

・ログフォーマットなど、柔軟なカスタマイズが可能

3

・実行詳細概要

- 意思決定 ID

- 日付

- 実行済みルール・セット・パス

- 処理時間

- 実行されたルールの数

- 実行されたタスクの数

・ルール・フロー・タスク・ツリーのある意思決定トレース

・入力パラメーター

・出力パラメーター

・実行の出力

1

ログ種類No

http://www.redbooks.ibm.com/redpapers/pdfs/redp4899.pdf

http://www.ibm.com/support/knowledgecenter/SSQP76_8.8.0/com.ibm.odm.dserver.rules.res.managing/topics/con_res_dw_overview.html

http://www.ibm.com/support/knowledgecenter/SSQP76_8.8.0/com.ibm.odm.dserver.rules.res.managing/topics/con_res_dw_overview.html


- 68 -

4 開発（編成）


- 69 -

ルール化方針ビジネス・ロジックの定義方法

ビジネス・ロジックは、ビジネス・ユーザーのメンテナンス対象とするかどうかを判断した上で、対称的なルールに関して

は可視性の高い意思決定表にて定義する。

意思決定表: 表形式でルールの集合をまとめて記述、管理することができる方法で、対称性のあるルールをまとめて記述すること

に向いている。各行に1つのルールが対応し、ルールの条件とアクションを列に定義する。特定の行の条件が満たさ

れた場合に、その行に定義されたアクションが実行される。・意思決定表の記述例（年収に対する信用度）

お客様要件（ビジネス・

ロジックの抽出）

BRMSで実行しない

BRMSで実行する

ODMの外側（業務アプリケーションなど）で実装する

ビジネス・ユーザーのメンテナンス対象

ビジネス・ユーザーのメンテナンス対象外

Java XOMとしてODM内部で定義する

アクション・ルールで定義する

意思決定表で定義する

語彙とBALを利用してODM内部で定義する

1行が1つのルールを表現

条件列アクション列

図 3-7-19 ビジネス・ロジックの定義方法選択

図 3-7-20 意思決定表の記述例


- 70 -

アクション・ルール: BAL（Business Action Language）を使用して記述する。構造としてルール内で使用する変数を定義する「定義」、ア

クション・ルールの条件を記述する「仮定条件」、実行するアクションを記述する「その場合」、「それ以外の場合」という

4つの部分を持つ。・アクション・ルールの記述例（氏名確認）

XOMの設計: Java XOMでは、本来はルール記述上に現れるべき計算処理や判断ロジックなどを実装することも可能である。しか

し、Java XOMの内部実装はビジネス・ユーザーがメンテナンスできないため、Java XOMに定義するメソッドにはロジ

ックが入り込まないようGetter/Setterによるフィールドへのアクセスに限定することが基本的な考え方になる。また、プ

ログラム言語的な制約に対応する処理の実装や不変の公式のように、長期間変化せず、ビジネス・ユーザーにとって

メンテナンス対象ではない処理をユーティリティーとして実装するクラスを用意することでルール記述が簡潔に行える

ようになる。・XOMの例（毎月の返済）

図 3-7-22 XOM の記述例

図 3-7-21 アクション・ルールの記述例


- 71 -

対象分野ルール化方針トピック編成（開発）タイトルビジネス・ロジックの定義方法 Id. AD-ODM-0411 説明ビジネス・ロジックを製品内部でどのように定義するか、基準を示す。前提ビジネス・ロジックの抽出作業が完了していること。制約なし要件ビジネス・ロジックをBRMSで定義したい。

基準下記の基準(A)、(B)を元に実装方法を定義する。 (A) ビジネス・ユーザーのメンテナンス対象 (B) ルールの対称性

候補

（1）意思決定表を使用して定義する <特徴> ビジネス・ユーザーのメンテナンス対象となる。表形式でルールの集合をまとめて記述、管

理でき、変更容易性/生産性/可視性が高い。対称的であるアクション・ルールの記載に向いている。（2）アクション・ルールを使用して定義する <特徴> ビジネス・ユーザーのメンテナンス対象となる。語彙とBAL（ビジネス・アクション言語）を利

用して定義でき、変更容易性/生産性が高い。（3） Java XOMで定義する <特徴> 複雑な処理を実装することが可能。ビジネス・ユーザーのメンテナンス対象にはならない。

変更容易性/生産性は低い。決定決定内容を記載決定理由決定した理由を記載影響なし派生要件 AD-ODM-0421 Utilityクラスの作成関連AD なし

参考資料

ODM V8.8.0 Knowledge Center： - 意思決定表 : http://www.ibm.com/support/knowledgecenter/SSQP76_8.8.0/com.ibm.odm.dcenter.bu.bconsole/dtables/con_bc_dtables_overview.html - アクション・ルール : http://www.ibm.com/support/knowledgecenter/SSQP76_8.8.0/com.ibm.odm.dcenter.bu.bconsole/arules/con_bc_arules_overview.html

ユーティリティー

Utility クラスの作成ルール・プロジェクト共通で使用する処理を記述したクラス（Java XOM）を Utility クラスとして定義する。 Utility クラスは、製品提供の System BOM（※）で定義できない場合についてのみ作成する。

ルールを記述するSystem BOMで

定義可

System BOMで定義不可

System BOMで対応する

Utilityクラスを作成する

図 4-2-1 System BOM と Utility 実装の場合分け

http://www.ibm.com/support/knowledgecenter/SSQP76_8.8.0/com.ibm.odm.dcenter.bu.bconsole/dtables/con_bc_dtables_overview.html

http://www.ibm.com/support/knowledgecenter/SSQP76_8.8.0/com.ibm.odm.dcenter.bu.bconsole/dtables/con_bc_dtables_overview.html

http://www.ibm.com/support/knowledgecenter/SSQP76_8.8.0/com.ibm.odm.dcenter.bu.bconsole/arules/con_bc_arules_overview.html

http://www.ibm.com/support/knowledgecenter/SSQP76_8.8.0/com.ibm.odm.dcenter.bu.bconsole/arules/con_bc_arules_overview.html


- 72 -

（※）System BOM とは、ルール・プロジェクトにデフォルトで用意されている BOM ： http://www.ibm.com/support/knowledgecenter/SSQP76_8.8.0/com.ibm.odm.dserver.rules.designer.author/config_auth_topics/con_rd_bom_intro.html

・Utility クラスの例（DateUtil クラス）

対象分野ユーティリティートピック編成（開発）タイトル Utilityクラスの作成 Id. AD-ODM-0421

説明 Utilityクラスを作成する基準について説明する。 Utilityクラスとは、ルール・プロジェクト共通で使用する処理を記述したクラスのこと。

前提ルールで実装する内容の抽出が完了していること。制約 UtilityクラスはXMLのXOMでは書けない。要件簡潔にルールを記述したい。基準 (A) 製品が提供している機能で実装可能か

候補

（1） System BOMのみで対応する <特徴> 製品で提供しているBOM。特定のJDKクラスにマッピングするクラス、および基本的な日付

および時間関連のクラスを含むクラスのセット。（2） Utilityクラスを作成する <特徴> Javaプログラミングによって複雑な処理が実装できる。

決定製品提供機能であるSystem BOMで定義できないものについてのみUtilityクラスを作成する決定理由同上影響なし派生要件 AD-ODM-0422 Utilityクラスの配置

System BOM一覧アクション・ルール

System BOM一覧アクション・ルール

図 4-2-2 System BOM の例

図 4-2-3 Utility クラスの例

http://www.ibm.com/support/knowledgecenter/SSQP76_8.8.0/com.ibm.odm.dserver.rules.designer.author/config_auth_topics/con_rd_bom_intro.html



- 73 -

関連AD AD-ODM-0411 ビジネス・ロジックの定義方法

参考資料 ODM V8.8.0 Knowledge Center：ビジネス・オブジェクト・モデル（BOM）の紹介 http://www.ibm.com/support/knowledgecenter/SSQP76_8.8.0/com.ibm.odm.dserver.rules.designer.author/config_auth_topics/con_rd_bom_intro.html




- 74 -

Utility クラスの配置各 BOM との依存性が高い場合（例：BOM のデータ構造に依存する場合）は、同じルール・プロジェクト内に配置する

・Utility クラスの例（LoanUtil クラス）

BOM との依存性が低く、他のルール・プロジェクトから共通に使われる場合は、専用のプロジェクトを作成して配置す

る（common プロジェクト化する）

・Utility クラスの例（DateUtil クラス）

ルール･プロジェクトABOM1BOM2

・・

ルール･プロジェクトUUtility1Utility2

・・

使用ルール･プロジェクトB

BOM10BOM11

・・

使用

ルール･プロジェクトABOM1BOM2

・・

Utility1Utility2

・・

図 4-2-4 同じルール・プロジェクト内への配置イメージ

図 4-2-5 同じルール・プロジェクト内に配置した Utility クラスの例

図 4-2-6 専用のルール・プロジェクトを作成した場合の配置イメージ

図 4-2-7 専用のルール・プロジェクトを作成て配置した Utility クラスの例


- 75 -

対象分野ユーティリティートピック編成（開発）タイトル Utilityクラスの配置 Id. AD-ODM-0422 説明 Utilityクラスをどのルール・プロジェクトに配置するか。前提 Utilityクラスで実装する内容の抽出が完了していること。制約なし要件 Utilityクラスの配置先を決めたい。基準 (A) BOMとの依存性

候補

（1） BOMと同じルール・プロジェクトに配置する - 例: 各BOMとの依存性が高い場合（データ構造に依存する場合）（2） Utilityクラス専用のルール・プロジェクトを作成し、配置する - 例: BOMとの依存性が低く、他のプロジェクトから共通に使われる場合（BOMまたは複数のインス

タンスをまたがって処理する場合）決定決定内容を記載決定理由決定した理由を記載影響なし派生要件なし関連AD なし参考資料なし


- 76 -

5 テスト

テスト方針ルール・セットを検証する際のテスト方針について説明する。ルール・セットは Java コードを基にした XOM や Java コードを必要としないルール・アーティファクトや BOM から構成

される。また、ビジネス・ルールの開発や変更はルール・オーナーが実施するため、ビジネス・ルールのテストについて

はルール・オーナーが実施する必要がある。 ODM におけるテストは通常のアプリケーションとは対象や実施者が異なるため、テスト種別と、そのスコープ、実施者

を明確にする。また、テスト・スコープの定義によっては、実施工数に影響を与える場合もあるため、プロジェクトの早い

段階でテスト方針を明確にすることは重要である。 ODM のテスト機能としては、Rule Designer から起動するテスト機能と、Decision Center から起動するテスト機能があ

る。前者はデバッグなどが可能であり、初期開発を行う開発者が利用することを想定している。後者は様々なデータ・

バリエーションを投入した場合の意思決定を確認することが可能であり、業務ユーザーの利用に適している。

テスト種別ごとのスコープ ODM におけるテスト種別ごとのスコープと、その担当者について定義する。

図 5-1-1 テスト種別ごとのスコープ


- 77 -

図 5-1-2 テスト種別ごとの担当と目的

システムテストおよび受け入れテストは、システム全体を対象としたテストとなるため、ルール開発の領域は単体テスト

および統合テストとなる。また、単体テストをアクション・ルールや意思決定表の単位で実施するかについては、ルー

ル・セットに依存する部分になるため、プロジェクト内で検討する必要がある。

ルール・オーナーによる単体テストの実施単位ルール・オーナーが主担当として実施する単体テストの実施単位はルール・セットであることが望ましいが、ルール・セ

ットの内容やプロジェクト体制によっては、ルール・セットを分割した単位で実施したい場合がある。それぞれの候補に

ついて検討する。候補(1)単体テストの実施単位をルール・セットとする

ルール・セットの一連の処理を実施単位とすると、開発したルール・プロジェクト

をそのまま使用して Decision Center でテストを実施する事ができる。しかしな

がら、以下の考慮は必要となる。

・ルール・アーティファクト数やタスク数が多い場合、テストケースの作成が煩

雑となるため、ルール・セットの内容は複雑にならないよう考慮が必要である。・ Decision Center のテスト・ファイル・テンプレートはルール・セットのインター

フェース（ルール・セット・パラメーター）に準ずる。ルール・セット・パラメーター

に指定するオブジェクトの構造が複雑であると、生成されるシナリオ・ファイル・

テンプレートも複雑となり、ルール・オーナーのシナリオ作成が困難となる。・各タスクのルール・オーナーが異なり、一連の処理に対するテストケースを作

成できる担当者がいない場合がある。その場合は、体制としてルール・セットに

対するルール・オーナーを据えることが望ましい。もしくは、ルール・オーナーご

とにルール・セットを生成する。・ Decision Center でのテスト機能は、デバッグなど内部の処理を確認する手

段がないため、あまりに複雑なルール・セットにて想定と異なる意思決定結果が

返ってきてしまった場合、修正箇所の発見は困難となる。オーナーは開発者へ

ルール・セットを差し戻し、期待する入出力を開発者へ連携して、開発者が問

題判別を行うことになる。

候補(2)単体テストの実施単位をタスクとする

図 5-1-3 ルール・セット単位のテスト


- 78 -

ルール・フローにおける各タスクを単体テスト

の実施単位をすると、タスク単位のテストケ

ースが作成しやすい。各タスクに複数ルー

ルが含まれる場合などに有効である。しかし

ながら、一連の処理を実施単位とした単体

テストについても実施は必要である。ルールの呼び出しは意思決定操作に対して

実行されるので、単体テスト用の呼び出し方

法を別途検討する必要がある。単体テスト用

の配布構成でバリデーターを利用する方法

や、単体テスト用にフローを定義する方法が

考えられる。

テスト実施工数は候補(1)よりも増えるため、プロジェクトの初期段階で、単体テストの実施単位を明確にしておくことが

望ましい。

ルール開発チームによる単体テストの実施単位ルール開発チームによる単体テストは Java XOM で開発された Java コード成果物を対象とする。アクション・ルールや

意思決定表は作成した時点で製品がその動作を保証するため、個々のテストは必ずしも必要ではない。また、必要に応じてルール・セットを対象とした単体テストも実施する。たとえば、ルール・フローが複雑な場合の動作

の確認などが想定される。フロー内の処理状況を確認しながらテストを行いたく、入出力のパラメーターが複雑な型で

ある場合には、Java のテスト・クライアントを準備して Rule Designer でデバッグ機能を利用しながらテストを実施する必

要があるだろう。

Tips 単体テスト実施時の Tips について記述する。

問題の分類テスト実施の結果として問題が発生した場合、通常のアプリケーションとは異なる複数の原因が存在する。以下に、そ

の原因について分類を行い、対応方法を記述する。問題が発生した際に、設計やコーディングの間違いを原因として

考えがちだが、要件が原因である場合も多い。

原因対応

分類説明

要件そもそも要件が間違っている。要件を見直す。

テストケースが間違っている。テストケースを修正して、再度テストする。

分析要件の分析・抽出が間違っている。分析・抽出の結果を修正して、再度テストする。

図 5-1-4 タスク単位のテスト

「資格」タスク

「資格」用の

テスト・データ

「資格」の応答

の期待値

「保険」タスク

「保険」用の


「保険」の応答

の期待値

「計算」タスク

「計算」用の


「計算」の応答

の期待値

「検証」タスク

「検証」用の


「検証」の応答

の期待値


- 79 -

要件の分析・抽出がモレている。対応の要否を判断する。

対応が必要な場合は、分析・抽出の結果に追加

して、再度テストする。

設計ルール・フローの設計、インターフェ

ース（ルール・セット・パラメーター）の

設計など。（※ルールの記述以外）

設計を修正して、再度テストする。

コーディングルールの記述ミス

（例えば、「入院保険金を～とする」と

すべきところを、「手術保険金を～と

する」に間違えているなど）

記述ミスを修正して、再度テストする。

シナリオ・ファイル・テンプレートの「予期した実行の詳細」シナリオ・ファイル・テンプレートを作成する際に「予期した実行の詳細」としてテスト実行時の以下の情報を結果として

得られる。・実行されたルール／実行されなかったルールの数・実行されたルール／実行されなかったルールのリスト・実行されたルール・フロー・タスク／実行されなかったルール・フロー・タスクの数・実行されたルール・フロー・タスク／実行されなかったルール・フロー・タスクのリスト・実行の期間テスト結果が想定通りでない場合、これらの情報を確認することは問題判別の際の重要な手掛かりとなるため、有効に

利用すべきである。


- 80 -

6 配布

ルール・セットの配布 ODM ではルール実行環境(RES)への配布方法として以下の４つの機能を使用する方法を提供している。・ Rule Designer ・ Decision Center Business Console ・ RES コンソール・ Ant タスク配布作業をシェルなどに組み込むコマンドベースで行いたい場合は、Ant タスクを使用する必要がある。その他は、手

動での実行となるが、担当者や環境の制約事項によって決定する。対象分野配布トピック配布タイトルルール・セットの配布 Id. AD-ODM-0601 説明ルール・セットをサーバー環境へ配布する際の手法を決定する前提 ODM機能を利用してルール・セットの配布を行う

制約要件としては、以下のものが明確であることが挙げられる。 ① サーバー環境へのネットワーク的な接続可否 ② 配布の自動実行の必要性

要件ルール運用管理においてルール・セット配布方法を決定する必要がある

基準 (A) 実行環境へのアクセス可否 (B) 自動化の必要性

候補

(1) Rule Designer ・Rule Designer環境からサーバー環境への接続が可能

(2) Decision Center Business Console ・Decision Center環境からサーバー環境への接続が可能

(3) RESコンソール・実施環境のブラウザからサーバー環境への接続が可能

(4) Antタスク・コマンドによる実行

決定 N/A 決定理由 N/A 影響なし派生要件配布担当者が実行権限を有する必要がある関連AD

参考資料

IBM Operational Decision Managerインフラ設計ガイド：アプリケーション・リリース http://www.ibm.com/developerworks/jp/websphere/library/decman/odm85_infra/ IBM Operational Decision Manager v8.6 ルール・ガバナンス・ガイド：サーバーへの配布 https://www.ibm.com/developerworks/jp/websphere/library/decman/odm_rulegov/

http://www.ibm.com/developerworks/jp/websphere/library/decman/odm85_infra/

https://www.ibm.com/developerworks/jp/websphere/library/decman/odm_rulegov/

Documents

ODM V8.8 アプリケーション・ デザイン・ガイド€¦ · 参考資料 参考とした資料のリンク、または、名前。 プロジェクト名 : ドキュメント名

ODM V8.8 アプリケーション・デザイン・ガイド€¦ · 参考資料参考とした資料のリンク、または、名前。プロジェクト名 : ドキュメント名