第7章 JBoss Developer Studio

JBoss Developer Studio アプリケーションは JBoss Rules で唯一サポートされる 統合開発環境 (IDE) で、多くのプログラマーにとって便利な機能を複数提供します。本章を読んで、これらの機能の使用方法について学びましょう。

注記

JBoss Rules IDE のコンポーネントは Eclipse プラグインとして個別に使用することも可能です。

注記

JBoss Developer Studio はルールの記述に必要ではなく、JBoss Rules エンジンは Eclipse 環境に全く依存しません。
概要

図7.1 概要

7.1. 概要

JBoss Developer Studio には以下の機能があります。
  • コンテンツアシスタント 機能 (outline view を含む) を提供する DRL 構文認識エディター
  • コンテンツアシスタント 機能を提供する ドメイン固有言語 拡張認識エディター
  • ルールフローグラフ (プロセスを表す) を編集するための Rule-Flow Graphical Editor。ルールフローグラフをルールパッケージに適用し、命令型制御 を許可できます。
  • 以下を作成するウィザード
    • 「rules」プロジェクト
    • ルールリソース ( DRL または BRL ファイルの形式)
    • ドメイン固有言語
    • ディシジョンテーブル
    • ルールフロー
  • カスタム言語とルール言語間のマッピングを作成および管理するための domain-specific language editor
  • ルール検証は、変更が行われるたびにルールを再構築します。Problem View よりエラーを報告します。

7.2. Drools ランタイム

Drools ランタイムは、Drools プロジェクト jar の 特定のリリースを 1 つ表す jar ファイルのコレクションです。ランタイムを作成するには、IDE を選択するリリースへ示す必要があります。プラグイン自体に含まれる最新の Drools プロジェクト jar に基づいて新しいランタイムを作成する必要がある場合も、簡単に行うことができます。Eclipse ワークスペースに対してデフォルトの Drools ランタイムを指定する必要がありますが、各プロジェクトはデフォルトを上書きすることができ、プロジェクトに対して適切なランタイムを選択することができます。

7.2.1. Drools ランタイムの定義

Eclipse 設定ビューを使用して 1 つ以上の Drools ランタイムを定義するには、「Window」メニューで「Preferences」メニュー項目を選択し、Preferences を開きます。「Preferences」ダイアログに設定がすべて表示されるはずです。このダイアログの左側にある Drools カテゴリー下で「Installed Drools runtimes」を選択します。右側のパネルに、現在定義されている Drools ランタイムが表示されるはずです。
新しい Drools ランタイムを定義するには、追加ボタンをクリックします。ダイアログが表示され、ランタイムの名前とランタイムが存在するファイルシステムの場所を入力するよう要求されます。
通常、2 つのオプションがあります。
  1. Drools Eclipse プラグインに含まれるようにデフォルトの jar ファイルを使用するには、「Create a new Drools 5 runtime ...」ボタンをクリックすると新しい Drools ランタイムを自動的に作成することができます。ファイルブラウザーが表示され、このランタイムを作成するファイルシステム上のフォルダーを選択するよう求められます。プラグインが必要な依存関係を自動的に指定されたフォルダーへコピーします。このフォルダーの選択後、ダイアログは下図のようになるはずです。
  2. 特定リリースの Drools プロジェクトを使用したい場合は、必要なすべての Drools ライブラリおよび依存関係が含まれるファイルシステム上にフォルダーを作成する必要があります。上記のように、新しい Drools ランタイムを作成する代わりにランタイムに名前を割り当て、必要な jar がすべて含まれるこのフォルダーの場所を選択します。
OK ボタンをクリックした後、新規作成されたランタイムの前にあるチェックボックスをクリックします。プロジェクト固有のランタイムが選択されなかった Drools プロジェクトのランタイムとしてデフォルトの Drools ランタイムは使用されます。
Drools ランタイムは必要な数だけ追加することができます。
デフォルトのランタイムを変更した場合、デフォルトのランタイムを使用しているプロジェクトがすべてクラスパスを適切に更新するようにするには、Eclipse を再起動する必要があることに注意してください。

7.2.2. Drools プロジェクトに対するランタイムの選択

Drools プロジェクトを作成するたびに (New Drools Project ウィザードを使用するか、Drools で既存の Java プロジェクトを右クリックし「Convert to Drools Project」アクションを使用して既存の Java プロジェクトを変換する)、プラグインは自動的に必要な jar をすべてプロジェクトのクラスパスに追加します。
新しい Drools プロジェクトを作成する時、プロジェクト固有の Drools ランタイムが指定されている場合以外は、プラグインはそのプロジェクトのデフォルトの Drools ランタイムを自動的に使用します。これを行うには、New Drools Project ウィザードの最後の手順で 「Use default Drools runtime」チェックボックスを選択解除し、ドロップダウンボックスで適切なランタイムを選択します。「Configure workspace settings ...」リンクをクリックすると、現在インストールされている Drools ランタイムを表示するワークスペース設定が開かれるため、そこに新しいランタイムを追加することができます。
プロジェクトプロパティーを開き、Drools カテゴリーを選択すると、いつでも Drools プロジェクトのランタイムを変更できます。「Enable project specific settings」チェックボックスを選択し、ドロップダウンボックスより適切なランタイムを選択します。「Configure workspace settings ...」リンクをクリックすると、現在インストールされている Drools ランタイムを表示するワークスペース設定が開かれるため、ここに新しいランタイムを追加することができます。「Enable project specific settings」チェックボックスの選択を解除すると、グローバル設定に定義された通りデフォルトのランタイムが使用されます。

7.3. ルールプロジェクトの作成

新しいプロジェクトウィザードの目的は、ルールを即座に使用するために実行可能なプロジェクトを設定することです。これにより、基本的な構造、クラスパス、サンプルルール、およびテストケースが設定されます。
新しいルールオブジェクトを作成する時、ルール、デシジョンテーブルおよびルールフローなどデフォルトのアーティファクトを追加するかどうかを選択します。これが土台となり、即座に実行できます。これをカスタマイズの土台として扱います。簡単な Hello World ルールを学習してください。
新しいルールプロジェクトの結果

図7.2 新しいルールプロジェクトの結果

新しく作成されたプロジェクトには、サンプルルールファイル (Sample.drl) が src/rules ディレクトリに含まれ、Drools エンジンでルールを実行するために使用できるサンプル Java ファイル (DroolsTest.java) も含まれます。これは、com.sample パッケージの src/java フォルダーに含まれます。実行時に必要な他の jar はすべて Drools Library と呼ばれるカスタムクラスパスコンテナにも追加されます。ルールを「Java」プロジェクトに保持する必要はまったくありません。これは、Eclipse を Java IDE としてすでに使用しているユーザーの利便性を考慮しています。

注記

厳密には、ルールを Java プロジェクトに保持する必要はありません。ここでは、JBoss Developer Studio を Java IDE としてすでに使用しているユーザーの利便性を考慮しています。

重要

JBoss Developer Studio は、使用するリソースが変更されるたびに自動的にルールの再構築および検証を行う JBoss Rules Builder と呼ばれる機能を提供します。Rule Project Wizard を使用してプロジェクトが作成されると、この機能はデフォルトで有効になります。また、他のプロジェクトに対してこの機能を手作業で有効にすることも可能です。

重要

ファイルに大量のルール (通常 500 個以上) が含まれる場合は、大量の処理が発生します。これは、ファイル変更のたびに、各ルールが再構築されるためです。これが問題になる場合、2 つの対処法があります。最も簡単な方法は一時的にビルダーを無効にすることです。これ以外に、大きなルールを .rule ファイルに移動する方法もあります。これらのファイルはビルダーによって無視されますが、ファイルに含まれるルールを検証するために単体テストで実行する必要があります。

7.4. 新しいルールの作成とウィザード

ルールを作成するには、.drl ファイル拡張子を持つ空ののテキストファイルを生成するか、Wizard を使用します。Control+N を押すか、ツールバーの JBoss Rules アイコンをクリックして Wizard のメニューを起動します。
ウィザードメニュー

図7.3 ウィザードメニュー

Wizard は、ルールリソースの生成に関するオプションを提示することでユーザーに入力を求めます (何を入力すればよいか分からない場合、入力した内容を後で変更できます)。
ルールファイルを格納するため、src/rules というディレクトリを作成し、適切に命名されたサブディレクトリを追加します。パッケージ名は必須で、Java のパッケージ名と似ていることに注意してください (関係するルールをグループ化する名前空間を確立します)。
新しいルールウィザード

図7.4 新しいルールウィザード

Wizard を実行すると、骨格またはスケルトンが作成され、「肉づけ」することが可能になります。このウィザードも他のウィザードと同様に任意のヘルパーであるため、使用したくない場合は使用する必要はありません。

7.5. テキストルールエディタ ー

Rule Editor は、ルールマネージャーおよび開発者が最も使用するツールです。 Rule Editor は、通常の JBoss Developer Studio テキストエディターの標準的な機能を備えています。その他に、「ポップアップ」コンテキストアシスタントも提供します。この機能にアクセスするには、Control キーと Space キーを同時に押します。
使用中のルールエディター

図7.5 使用中のルールエディター

Rule Editorは、.drl または .rule 拡張子を持つファイルを開くことができます。通常、これらのファイルには関連する複数のルールが含まれますが、個別のファイルに各ルールが含まれるようにし、同じパッケージ名前空間に存在する利点を生かしてグループ化することも可能です。

注記

DRL ファイルのデータはプレーンテキスト形式で保存されます。
上記の例では、ルールグループはドメイン固有言語を使用しています。expander キーワードが存在することに注意してください。これは、ルール言語を解決するため、その名前の .dsl ファイルを検索するようルールコンパイラーに指示します。ドメイン固有言語が使用可能であっても、ルールはプレーンテキストとして格納され、画面上で表示できる内容を反映します。これにより、バージョンを比較する場合など、ルールの管理が非常に簡単になります。
editor は outline view を提供します。これは、ルール構造と同期化されます (ファイルが保存されるたびに更新されます)。この機能を使用して、迅速および効率的に名前でルールを見つけることができます。これは、数百ものルールが含まれる大型のファイルで使用すると大変便利です。デフォルトでは、項目がアルファベット順に表示されます。
ルールアウトラインビュー

図7.6 ルールアウトラインビュー

7.6. ガイド付きエディター

JBoss Developer Studio には Guided Editor と呼ばれる機能も含まれています。この機能は BRMS で使用できる Web ベースのエディターと似ています。この機能により、ルールを視覚的に構築することができます。
ガイド付きエディター

図7.7 ガイド付きエディター

このツールを使用してルールを作成するには、次の手順に従います。
  1. Wizard メニューをクリックします。
  2. .brl ファイルを作成し、Guided Editor で開きます。

    注記

    Editor は、.brl ファイルと同じディレクトリにある .package を使用して動作します。このファイルには、通常の .drl ファイルの上部にあるようなパッケージ名とインポートステートメントが含まれます。
  3. パッケージファイルに必要な fact クラスを追加します。
  4. この情報を追加したら、Guided Editor によって示されたプロンプトに従います (ファクトと関連するフィールドが表示されます)。
model または fact クラスが提供されたら、Guided Editor はルールの視覚的な表現をレンダリングすることができます。また、これを使用し、ビジネスルール言語を直接使用してルールを構築することもできます。これを実現する方法の 1 つが drools-ant モジュールを使用する方法です。このモジュールは、ルールアセットをディレクトリのルールパッケージとして作成するため、バイナリファイルとしてデプロイすることが可能になります。また、以下のコードスニペットを使用して、BRL ファイルを .drl ルールに変換する方法もあります。

例7.1 変換コード

BRXMLPersitence read = BRXMLPersitence.getInstance();
BRDRLPersistence write = BRDRLPersistence.getInstance();
String brl = ... // read from the .brl file as needed...
String outputDRL = write.marshall(read.unmarshal(brl));
// Pass the outputDRL to the PackageBuilder, as usual

7.7. JBoss Rules ビュー

ビューを使用して、アプリケーションのデバッグ時に JBoss Rules エンジンの状態をチェックします。Working Memory View、Agenda View および Global Data View の 3 つのビューが提供されます (Audit View もあります)。これらのビューを使用するには、working memory を起動するコードでブレークポイントを作成します (workingMemory.fireAllRules() を呼び出す行が適しています)。デバッガーが joinpoint で停止した場合、Debugging Variables ビューで working memory 変数を選択します。次に、次の機能を使用して選択されたworking memory の詳細を表示します。
  • Working Memory View には JBoss Rules の working memory にある要素がすべて表示されます。
  • 名前の通り、Agenda View には agenda の要素がすべて表示されます (各ルールの名前とバインドされた変数が表示されます)。
  • Global Data View には、現在 JBoss Rules のworking memory に定義されているグローバルデータがすべて表示されます。
  • Audit View には、rules engine が実行された時に生成された監査ログがツリー形式で表示されます。

7.7.1. Working Memory View

Working Memory View には、Drools エンジンのワーキングメモリーの要素がすべて表示されます。
表示内容をカスタマイズするため、ビューの右側にアクションが追加されます。
Show Logical Structure アイコンをクリックして、 working memory にある各要素の 論理構造 の表示と、要素の詳細表示を切り替えます。論理構造では要素のセットを簡単に視覚化できます。AgendaItems の論理構造は、ルールとそのルールによって使用される全パラメーターの値を表示します。

7.7.2. Audit View

次のコードを使用して監査ログを作成します。

例7.2 監査ログの設定

WorkingMemory workingMemory = ruleBase.newWorkingMemory();
// Create a new Working Memory Logger, that logs to file.
WorkingMemoryFileLogger logger = new WorkingMemoryFileLogger(workingMemory);
// An event.log file is created in the subdirectory log (which must exist)
// of the working directory.
logger.setFileName( "log/event" );

workingMemory.assertObject(...);
workingMemory.fireAllRules();

// stop logging
logger.writeToDisk();
Audit View の最初のアイコンである Open Log アクションをクリックしてログを開きます。すると、Audit View にルール実行中に記録された全イベントが表示されます。イベントのタイプによってアイコンが異なります。
  1. 挿入されたオブジェクト (緑色の正方形)
  2. 更新されたオブジェクト (黄色の正方形)
  3. 削除されたオブジェクト (赤色の正方形)
  4. 作成されたアクティベーション (右矢印)
  5. キャンセルされたアクティベーション (左矢印)
  6. 実行されたアクティベーション (青色の菱形)
  7. 開始または終了したルールフロー (「プロセス」アイコン)
  8. アクティベートまたはアクティベート解除されたルールフローグループ (「アクティビティ」アイコン)
  9. 追加または削除されたルールパッケージ (「JBoss Rules」アイコン)
  10. 追加または削除されたルール (「JBoss Rules」アイコン)
すべてのイベント記録は、イベント発生の追加情報を提供します。ワーキングメモリーのイベントでは (挿入、変更、取り消しなど)、詳細にオブジェクトの id と toString 表現が含まれます。アクティベーションイベントでは (作成済み、キャンセル済み、実行済みなど)、詳細にルール名とアクティベーションにバインドされたすべての変数が含まれます。

注記

アクティベーションの実行中にイベントが発生した場合、その実行の子として表示されます。
イベントの原因を調査するにはイベントを選択します。原因が判明している場合、緑色で表示されます。または、アクションを右クリックして Show Cause メニューエントリーを選択します。これにより、ログで原因が記録された場所にカーソルが移動します。

注記

オブジェクト「modification」または 「retraction」の原因は、そのオブジェクトの最後のイベントとして記録されます。これは、同じオブジェクトに対する 「object asserted」または最後の「object modified」イベントのいずれかです。
「activation canceled」または「executed」イベントの原因は、対応する「activation created」イベントです。

7.8. ドメイン固有言語

ドメイン固有言語では機能的に英語のルールを記述できるカスタム言語を作成できます。つまり、ドメイン固有言語は自然言語のように読み取ります。使用するには、次の手順に従います。
  1. ビジネスアナリストが独自の言葉でどのように記述するか注意してください。
  2. ルールコンストラクトよりこれをオブジェクトモデルへマッピングします (ドメインオブジェクトとルール自体の間で隔離レイヤーを提供できることも利点となります)。

注記

ルールの数が増えるとドメイン固有言語も大きくなります。一般的な用語を異なるパラメーターで繰り返し使用すると最も効率的です。

注記

Rule Workbench はドメイン固有言語のエディターを提供します (言語はプレーンテキスト形式で格納されるため、好きなエディターを使用することができますが、Rule Workbench ツールは Properties ファイル形式の若干改良されたバージョンを提供する利点があります)。
Editor は .dsl 拡張子を持つ任意のファイル上で起動されます (.dsl ファイルのサンプルを作成する wizard もあります)。

7.8.1. 言語の編集

ドメイン固有言語エディター

図7.8 ドメイン固有言語エディター

Domain-Specific Language Editor は言語のルール形式へのマッピングのタブ形式ビューを提供します (「Language Expressions」はルールで使用されるものです)。Domain-Specific Language Editor は Rule Editor の コンテンツアシスタント もフィードします。そのため、言語式をドメイン固有言語設定へ提示できます (rule resource ファイルが開かれた時に Rule Editor はこの設定をロードします)。ルールの言語マッピングは、rule engine によって言語式がコンパイルされる「コード」を定義します。
ルール言語式で使用される形式は、ルールの「条件」または「アクション」部分を対象にするかどうかによって異なります (右側の場合、Java の断片になることがあります)。scope 項目は式がどこに属するかを示します。when は左側を示し、then は右側を示します。* は「どこでも」という意味です。

注記

キーワードのエイリアスを作成することも可能です。
マッピングアイテム (テーブルの行) を選択し、テーブルの下にあるテキストフィールドの式とマッピングを確認します。これをダブルクリックするか、edit ボタンを押すと、 Edit ダイアログボックスが表示されます。ここで項目を削除したり追加したりすることが可能です。

警告

必ず、式が使用されていないことを確認してから項目を削除してください。
言語マッピングエディターのダイアログ

図7.9 言語マッピングエディターのダイアログ

変換処理は次のように行われます。
  1. パーサーが DSL ファイルのルールテキストを読み取り、スコープに応じて言語式に対して行ごとに一致しようとします。
  2. 一致した場合、括弧内のプレースホルダー ({age} など) に対応する値がルールソースより抽出されます。
  3. 「Rule Expression」のプレースホルダーは、対応する値に置き換えられます (上記の例では、自然言語式は「age」および「location」フィールドと、元のルールテキストより抽出された {age} および {location} 値に基づいて、「Person」型のファクトの 2 つの制約へマッピングします)。

注記

.drl ファイルの特定のルールに対して言語マッピングを使用したくない場合は、式の先頭に > を付けるとコンパイラーによって無視されます。また、ドメイン固有言語は任意であることにも注意してください。
ルールがコンパイルされると、.dsl ファイルも使用可能である必要があります。

7.9. Rete View

Rete Tree View は現在の .drl ファイルに対する Rete Network を表示します。表示するには、DRL Editor ウインドウの下部にある Rete Tree というタブをクリックします。表示されると、個別のノードを「ドラッグアンドドロップ」し、最適な概観を調整します (これらのノード上で長方形をドラッグし、複数のノードを選択することもできます。こうすることで、グループ全体を移動することができます)。JBoss Rules IDE ツールバーの拡大アイコンは、慣習的なやり方で使用できます。

注記

今後のバージョンでは、Rete Tree をイメージとしてエクスポートできるようになる予定です。この機能が導入されるまで、スクリーンショットを回避策として使用してください。
Rete View は、JBoss Developer Studio の グラフィカル編集フレームワーク を完全活用する高度な機能です。

重要

この機能は JBoss Rules プロジェクトでのみ使用可能です。JBoss Rules Builder はプロジェクトのプロパティーで設定されます。

7.10. 大型の .drl ファイル

使用される Java Development Kit によっては、permanent generation 設定の最大サイズを増やす必要がある場合があります。SUN および IBM の JDK には permanent generation 設定がありますが、BEA の JRockit にはありません。
permanent generation のサイズを増やすには、-XX:MaxPermSize=###m を用いて JBoss Rules IDE を起動します。例は次の通りです。
例: c:\Eclipse\Eclipse.exe -XX:MaxPermSize=128m
4000 以上のルールがある場合に備えて、permanent generation を最低でも 128 Mb に設定してください。

注記

これは、一般的に大量のルールをコンパイルする場合でも同様です。通常、1 つのルールに 1 つ以上のクラスがあるためです。
この代わりに、.rule 拡張子を持つファイルにルールを格納することもできます。これを行うと、background builder は変更のたびにルールをコンパイルしないようになります。これにより、パフォーマンスが向上されます (特に、非常に大量のルールを処理する時に IDE の動作が遅い場合)。

7.11. ルールのデバッグ

JBoss Rules の実行中にルールをデバッグすることが可能です。ルールの consequences にブレークポイントを追加できます。ルール実行中にこのようなブレークポイントが検出されると処理が停止されるため、そのポイントで既知の変数をチェックし、デフォルトのデバッグアクションを使用して次に行う処理を決定することができます。また、Debugging View を使用して working memory と agenda の内容を調査することも可能です。

7.11.1. ブレークポイントの作成

次の 2 つの方法のいずれかを用いて、ルールのブレークポイントを追加または削除します。
  1. ブレークポイントを追加する行で DRL Editor の Ruler をダブルクリックします。

    重要

    このようなブレークポイントは、ルールの consequence のみで作成できます。ブレークポイントが許可されない行をダブルクリックしても何も行われません。
    ブレークポイントを削除するには、再度 Ruler をダブルクリックします。
  2. ルーラーを右クリックすると、「Toggle breakpoint」アクションが含まれるポップアップメニューが表示されます。ルールブレークポイントはルールの結果でのみ作成できることに注意してください。ルールブレークポイントがその行で許可されない場合、アクションは自動的に無効になります。アクションをクリックすると、選択された行にブレークポイントが追加されますが、ブレークポイントがすでに存在する場合はブレークポイントが削除されます。
Debug Perspective には Breakpoint View が含まれます。これを使用して、定義されたブレークポイントをすべて確認し、プロパティーを取得して有効、無効、または削除します。

7.11.2. ルールのデバッグ

ブレークポイントを有効にするには、プログラムを JBoss Rules Application としてデバッグする必要があります。
JBoss Rules アプリケーションとしてのデバッグ

図7.10 JBoss Rules アプリケーションとしてのデバッグ

  1. アプリケーションのメインクラスを選択し、右クリックします。Debug As サブメニューを選択した後に JBoss Rules Application を選択します。
    この代わりに Debug ... メニューアイテムを選択することもできます。この場合、デバッグ設定を作成、管理、および実行するための新しいダイアログボックスが表示されます (以下のスクリーンショットを参照)。
  2. 左側の tree で JBoss Rules Application アイテムを選択し、New Launch Configuration ボタン (tree の上にあるツールバーの一番左にあるアイコン) をクリックします。これにより、すでに一部のプロパティーが設定された (プロジェクトやメインクラスなど) 新しい設定が作成されます (最初に選択したメインクラスに基づきます)。これらすべてのプロパティーは標準的な Java プログラムのプロパティーと同じです。
  3. デバッグの設定の名前を意味のある名前に変更します。
  4. アプリケーションのデバッグは開始するには、ウインドウの下にある Debug ボタンをクリックします。
    デバッグ設定は一度だけ設定する必要があります。次回デバッグが必要な時は同じ設定を使用します。

    注記

    JBoss Rules IDE ツールバーには、以前の設定の 1 つを即座に再実行するショートカットボタンも含まれています (少なくとも Java、Java Debug、または JBoss Rules の 1 つが選択された時)。
「Debug as JBoss Rules Application」の設定

図7.11 「Debug as JBoss Rules Application」の設定

Debug ボタンをクリックすると、アプリケーションが実行を開始し、ブレークポイント (JBoss Rules のルールブレークポイントまたは他の標準的な Java ブレークポイント) が検出されると停止します。JBoss Rules のルールブレークポイントが検出されると、対応する DRL ファイルが開かれ、アクティブな行が強調表示されます。Variables View には、ルールパラメーターすべてと、それらのパラメーターに関連する値が含まれています。
デフォルトの Java デバッグアクションを使用して、次に行う処理 (再開、終了、または行のステップオーバー) を決定します。その時点で、Debug View を使用して working memory と agenda の内容を調査することも可能です (現在実行されているものが自動的に表示されるため、この時点で working memory を選択する必要はありません)。
デバッグ

図7.12 デバッグ