(この記事は、ノースアメリカ在住の Red Hat シニアコンサルタント John Hurlocker との共同執筆です)
今回の tips and tricksでは、ルールプロジェクトに参加した際に経験するであろうデザインサイクルについて、いくつかバックグラウンドやガイドラインを紹介します。
この記事では、ルールやイベントを取り扱ったプロジェクトが発展していく方法が記載された唯一の基準(standard)でもすべて網羅した記事でもありません。
この記事では、現実世界で組織がかかえるプロジェクトを多数経験してきたうえで基礎といえる内容をご案内します。JBoss BRMSを利用し独自のルールやイベントを活用していこうとされているあなたにとって、自信を与えるよう意図して執筆しました。
ルール開発関連でおこなわれる要件定義について考察します。その他、プロジェクトのトレーサビリティを要求された場合に選択できるオプションや、これから経験されるであろうデザインの選択肢について触れます。
1.要件
ルール作成者はプロジェクト要件を担当するチームメンバーと協力してプロジェクト要件を解析し、実装する必要のあるルール数を見積ります。チームメンバーと協力することで、質問がでた時に即座に回答を得ることができます。ルール作成の為に要件を解析する際、以下の質問がでてくるでしょう:
- 要件をレビューする際、WHENやTHENが明解ではない状況(condition)はありますか?
- データを検証する為のルールは含まれていますか?
- 複数の要件を１つのルールにまとめることはできますか？
これらの質問は、以前の tips and tricksで取り上げられた内容です。
2.デザイン
デザインフェーズでは、企業のルール管理者は組織と一緒に働き、下記質問からいくつか問い合わせる必要がでてきます:- 組織は、セントラル ルール リポジトリをホストする必要がありますか？ ホストすることは有益ではないですか？
- ルールの所有者は誰ですか？ルールを更新したり新バージョンをリリースする責務を持っていますか？
- グループ間で再利用可能な共通ルールはありますか？
 |
| セントラル JBoss BRMS リポジトリ |
組織内に複数リポジトリを配備するよりもメンテナンス性にすぐれており、ルールの再利用を促進します
複数グループ間で特定のルールが共有される場合、必ずどちらかのグループがオーナーシップを持ち、ルールの更新や新バージョンのリリースに対する責務を負うべきです
ルール作成者は、アプリケーションチームと一緒に働き、ルールのフォーマットやオーサリングツールを決定する必要があります。下記質問について話し合われるべきです:
- BRMS Dashboard と JBoss Developer Studio(JBDS)のどちらでルールは開発されるべきですか？
- ルール作成者がより快適でいられる要素は何ですか？
- 将来、誰がルールをメンテナンスしますか？
- Java開発者ですか？、ビジネスアナリストですか？
- どのフォーマットが要件に適していますか？
- e.g. webベースのデータテーブルですか？ business guided ruleですか？ DSLですか？
- どのようなタイプのテストが必要ですか？
- JUnit と BRMSテストシナリオですか？
3.トレーサビリティ
 |
| 要件のトレーサビリティ用途に使えるメタデータオプション |
- descriptionセクションに、関連要件を設定することができます
- 関連要件は、外部リンクとしてルールのメタデータに設定することができます
- リポジトリからメタデータ情報を取得することで、レポートを作成することが可能です
原文: 3 Simple Guidelines to Rule Development, Design and Traceability by Eric D. Schabell
ルールを使ったプロジェクト開発を検討されている方はぜひご確認ください。プロジェクトの初期段階で検討しておくべき項目がリストアップされていますよ。Red Hat コンサルタントとエバンジェリストによる執筆なので、経験に裏打ちされた情報です。
返信削除個人的にぐっときたのは、「将来ルールを更新・管理する責務を持つのは誰か」です。誰にするかで、なぜルールを使ったプロジェクトを検討したか見えてきそうなお題だと感じました。