Task: Build Rule Project Structure |  |
Designing and building how the rule will be managed is an important activity of a BRMS project. This task describes how to build the set of rule and non rules projects that support the business application.
Disciplines: Rule Design
Purpose
Build a project structure which helps to easily manage the rules, the application code, and the domain object model. The application design is based on a n-tier architecture, with a service layer which includes rule services.
Relationships
Roles | Primary Performer: Rule Analyst Rule Architect | Additional Performers:
Main Description
This activity is linked to the tool used. There is still some considerations when designing the project structure for the rules and application: Apply good design practice of implementing the application using a n-tier approach. The service layer includes the interfaces of the rule decision service entries. Organize rule project so that a few person can concurrently work on rule artifact at the same time. Organize rule project so that they are manageable in term of performance at the execution and at the rule authoring level. Separate representation of the domain object model in java project.
Steps
Create projects structure
Using Eclipse for Java project or Visual Studio for .Net development, the developer needs to create the project structure with at least the following projects: A java project for the Executable object model that supports the Domain Object Model as described in the Logical Data Model Rule projects. By design the rule project, the architect needs to try to map one rule set per rule project. A java project for the Core business application, including service interface definition of the rule services GUI project like web interface using the code business application Within a rule project defines: The rule set parameters The references to the object model used The rule flow structure, at least a first simple version that will be enhanced during the future iterations Some initialization method or function to be able to unit test the rule project
For each rule projects, specify the objects to be manipulated by the ruleset
This includes rule set parameters, but also the underlying object model used by the rules.
Create a Natural Language Layer on top of the data model
Define rule meta properties
The development team need to define each rule’s meta properties to be used during rule management and rule execution (filtering of rules or reporting on rule execution. The common properties are: Rule ID, author, owner: to trace the rule changes Expiration date, Effective date: to filter the rule according to time The status to manage the rule life cycle to avoid deploying rule in development stages Business motivation, Policy reference, requirement reference: to reference rule back to the requirements Product reference, states, geographies: to manage rule per type of deployment or other dimension of application The following tables lists some example of properties an analyst can design to manage a rule:
Property name | Type | Possible Value | Description | Null able | Changeable | Extractable | Required
Rule ID | Int or string |  | Unique identifier for the rules | No | No | Yes | Yes
BusinessMotivation | String | “” | Link the rule to the business motivation | Yes | Yes | No | No
PolicyReference | String | “” | Link the rule to a business policy | Yes | Yes | No | No
Status | String | New, Defined, Deployable, Deployed | Support the life cycle of the rule | No | Yes | Yes | Yes
Rule Owner | String |  | Department team – no named person | Yes | Yes | No | Yes
Expiration Date | Date |  | Date when the rule will not be extracted | Yes | Yes | No | No
Effective Date | Date |  | Date from when the rule will be extracted | Yes | Yes | No | No
Document Rule Set interface
Use the rule set table template to present how the rule services are designed
ABRD Practice Copyright.