(Article guest authored together with John Hurlocker, Senior Middleware Consultant at Red Hat in North America)
In this tips and tricks article we present some background and guidelines for the design cycle encountered when one is working with rules projects.
This article is not the only standard or all encompassing source of how each and every rules and events project will evolve over time.
What it is going to do is provide you with the basics as we have encountered them in many projects in real life organizations. They are meant to give you some confidence as you embark on your very own rules and events adventure within the world of JBoss BRMS.
We will discuss some of the requirements phase around rules development, touch on a few of the design choices that will be encountered and elaborate on the options available for including requirements traceability within the projects.
1. Requirements
A rule author will analyze project requirements to determine the number of rules that will need to be created and also works with the requirements team so they can provide answers to any questions that might arise.
Analyzing rules requirements is the phase where a look at the following questions takes place:
- Are there any WHEN or THEN conditions that are unclear when reviewing the requirements?
- Are some of these rules data validations?
- Can multiple requirements be combined into one rule?
By spending some pre-development time examining and validating the project requirements you will be able to narrow the scope of the work to be done in your development cycles.
These questions have been dealt with in previous articles in the tips and tricks.
2. Design
In the design phases an enterprise rule administrator will need to work with the organization and ask some of the following questions:
- Will the organization need to host a central rules repository or would that not be beneficial?
- Who owns these rules and is responsible for updating and releasing new versions?
- Are there common rules that can be reused between groups?
A central repository is one JBoss BRMS server available for the entire organization to author, store, and build rules.
It promotes rule reuse, is easier to manage and maintain instead of deploying multiple repositories in an organization.
If a set of rules is going to be shared with other groups then one of the groups will need to take ownership and will be responsible for updating and releasing new versions.
The rule author will need to work with the application team(s) to determine what rule format or formats will be used and which tool will be used to author rules. Some of the questions to be dealt with are:
- Should rules be developed in the BRMS Dashboard or through JBoss Developer Studio (JBDS)?
- What are your rule authors more comfortable with?
- Who will maintain the rules in the future?
- Java developers, business analysts
- Do the requirements work better in one format vs. another?
- e.g. web based data table, business guided rule, DSL
- What type of testing is required?
- JUnit and BRMS test scenarios?
These topics have been laid out in previous articles, please refer to them for a deeper discussion.
3. Traceability
Once the rules and events are being implemented it is vital to have some sort of requirements traceability attached to the rules that links them to the originating requirements.
With JBoss BRMS rule authors can set meta data on the rules for traceability to requirement(s), for instance:
- Associated requirements can be set on rules in the description section.
- Associated requirements can also be set as an external link on the rule meta data.
- Reports can be generated by pulling meta data information from the repository.
In a future article we will dig deeper into how you can use meta data fields within your rules implementation to trace your requirements and extract this information to generate documentation around these requirements.
| Reference: | 3 Simple Guidelines to Rule Development, Design and Traceability from our JCG partner Eric Schabell at the Eric Schabell’s blog blog. |
