| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:TaskDescription xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmlns:rmc="http://www.ibm.com/rmc" |
| rmc:version="7.5.0" xmi:id="-kaG_G7QLbZmoHMO8_47GiQ" |
| name=",_8mZw8DmhEdy8N6BRpa8ByQ" guid="-kaG_G7QLbZmoHMO8_47GiQ" authors="Jerome Boyer" |
| changeDate="2008-09-08T11:02:32.765-0700"> |
| <mainDescription><p>
 |
| Rule Analyst has to study the rule discovered and try to transform it so that the implementation and the management of
 |
| the rule will be more easy. This includes transforming the rule in atomic element using a syntax without ambiguity,
 |
| remove redundant rules, conflicting rules, and finally try to redefine the scope of the rule by searching by
 |
| non-handled cases.&nbsp;
 |
| </p>
 |
| <p>
 |
| At this stage rule analyst can build some rule template which&nbsp;are built from rules that have the same set of
 |
| conditions with some little variations: adding new value in test condition, or new condition.
 |
| </p></mainDescription> |
| <keyConsiderations>This activity will also be done during the implementation of the rule set, but it is started during the analysis, so we are
 |
| detailing it in this context.</keyConsiderations> |
| <sections xmi:id="_7HEPsDmiEdy8N6BRpa8ByQ" name="Refine Rule as Atomic" guid="_7HEPsDmiEdy8N6BRpa8ByQ"> |
| <sectionDescription><p class="MsoNormal" style="MARGIN: 3pt 0cm; mso-list: l0 level2 lfo1; tab-stops: list 72.0pt" type="disc">
 |
| <span
 |
| style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">A
 |
| rule is atomic if it cannot be further decomposed without losing meaning. Atomicity is desired for understandability,
 |
| ease of maintenance</span>
 |
| </p>
 |
| <div style="MARGIN-TOP: 0cm; MARGIN-LEFT: 2em" type="disc">
 |
| <ul style="MARGIN-TOP: 0cm" type="disc">
 |
| <li class="MsoNormal" style="MARGIN: 3pt 0cm; mso-list: l0 level2 lfo1; tab-stops: list 72.0pt">
 |
| Make sure each rule has one result
 |
| </li>
 |
| <li class="MsoNormal" style="MARGIN: 3pt 0cm; mso-list: l0 level2 lfo1; tab-stops: list 72.0pt">
 |
| When expressed an inference rule or an action enabler, do not allow ANDs on the right hand side; break the rule
 |
| </li>
 |
| <li style="LIST-STYLE-TYPE: none">
 |
| <ul style="MARGIN-TOP: 0cm" type="disc">
 |
| <li class="MsoNormal" style="MARGIN: 3pt 0cm; mso-list: l0 level3 lfo1; tab-stops: list 108.0pt">
 |
| IF A THEN do(B) AND do(C)<span style="mso-spacerun: yes">&nbsp;&nbsp;</span> can be rewritten as two
 |
| rules IF A THEN do(B) and IF A THEN do(C)
 |
| </li>
 |
| </ul>
 |
| </li>
 |
| <li class="MsoNormal" style="MARGIN: 3pt 0cm; mso-list: l0 level2 lfo1; tab-stops: list 72.0pt">
 |
| When expressing an inference rule or an action enabler, do not allow ORs on the left hand side; break the rule
 |
| </li>
 |
| <li style="LIST-STYLE-TYPE: none">
 |
| <ul style="MARGIN-TOP: 0cm" type="disc">
 |
| <li class="MsoNormal" style="MARGIN: 3pt 0cm; mso-list: l0 level3 lfo1; tab-stops: list 108.0pt">
 |
| IF A OR B THEN do(C) can be rewritten as two rules IF A THEN do(C) and IF B THEN do(C)
 |
| </li>
 |
| </ul>
 |
| </li>
 |
| <li class="MsoNormal" style="MARGIN: 3pt 0cm; mso-list: l0 level2 lfo1; tab-stops: list 72.0pt">
 |
| When expressing constraints and guidelines, do not allow for ANDs
 |
| </li>
 |
| <li style="LIST-STYLE-TYPE: none">
 |
| <ul style="MARGIN-TOP: 0cm" type="disc">
 |
| <li class="MsoNormal" style="MARGIN: 3pt 0cm; mso-list: l0 level3 lfo1; tab-stops: list 108.0pt">
 |
| A driver must be 25 years old or older AND must have good credit rating
 |
| </li>
 |
| <li class="MsoNormal" style="MARGIN: 3pt 0cm; mso-list: l0 level3 lfo1; tab-stops: list 108.0pt">
 |
| A driver must be 25 years old or older; a driver must have good credit rating
 |
| </li>
 |
| </ul>
 |
| </li>
 |
| <li class="MsoNormal" style="MARGIN: 3pt 0cm; mso-list: l0 level2 lfo1; tab-stops: list 72.0pt">
 |
| Make sure that each rule contains only necessary conditions; don't over-constrain the rule applicability
 |
| </li>
 |
| </ul>
 |
| </div></sectionDescription> |
| </sections> |
| <sections xmi:id="_tFwpYDmoEdy8N6BRpa8ByQ" name="Remove redundant rules" guid="_tFwpYDmoEdy8N6BRpa8ByQ"> |
| <sectionDescription><p class="MsoNormal" style="MARGIN: 3pt 0cm 3pt 18pt">
 |
| This step is important to avoid developing complex rule sets. Redundant rules are
 |
| </p>
 |
| <div style="MARGIN-TOP: 0cm; MARGIN-LEFT: 2em" type="disc">
 |
| <ul style="MARGIN-TOP: 0cm" type="disc">
 |
| <li class="MsoNormal" style="MARGIN: 3pt 0cm; mso-list: l0 level2 lfo1; tab-stops: list 72.0pt">
 |
| Duplicated rules
 |
| </li>
 |
| <li class="MsoNormal" style="MARGIN: 3pt 0cm; mso-list: l0 level2 lfo1; tab-stops: list 72.0pt">
 |
| Duplicated through some transformations (renaming, inversion of conditions, etc.)
 |
| </li>
 |
| <li class="MsoNormal" style="MARGIN: 3pt 0cm; mso-list: l0 level2 lfo1; tab-stops: list 72.0pt">
 |
| Redundancies among rules that create a common data value or a common truth value, or initiate a common action
 |
| </li>
 |
| </ul>
 |
| </div>
 |
| <p class="MsoNormal" style="MARGIN: 3pt 0cm">
 |
| <span lang="EN-CA" style="mso-ansi-language: EN-CA"><span style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;</span>
 |
| This step is made simpler if we make the rules atomic, for otherwise, we will be lost in the equivalence of complex
 |
| logical formulas (e.g. If NOT (A AND B) is equivalent to<span style="mso-spacerun: yes">&nbsp;</span> IF (NOT A) OR
 |
| (NOT B)). There are for sure more subtle forms of redundancy: IF A AND B THEN C is equivalent to IF (NOT C) THEN (NOT
 |
| A) OR (NOT B). Some time changing the order of conditions can help to highlight same rules: <span
 |
| style="mso-spacerun: yes">&nbsp;</span>IF A AND B THEN C is the same as IF B AND A THEN C</span>
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_vMBLQDmoEdy8N6BRpa8ByQ" name="Remove inconsistency rules" guid="_vMBLQDmoEdy8N6BRpa8ByQ"> |
| <sectionDescription><p>
 |
| <span
 |
| style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Overlapping
 |
| rules are partially redundant because they are not semantically equivalent but they point to problems: One rule may say
 |
| IF A AND B THEN C, the other says IF A THEN C. The question is, is B really needed to infer C? One of the two rules
 |
| should be eliminated.</span>
 |
| </p>
 |
| <p>
 |
| It is also possible to get semantically equivalent conditions, contradictory conclusions: two rules like IF A THEN B;
 |
| and IF A THEN NOT(B) are leading us to have two conflicting rules, probably coming from two different sources.
 |
| Typically, this is symptomatic of the fact that we are missing some necessary conditions in either rule (or both, e.g.:
 |
| IF A AND C THEN B; IF A AND D THEN NOT(B))
 |
| </p>
 |
| <p>
 |
| Another standard case is around the same conclusions derived from contradictory conditions: rules like IF A THEN B;
 |
| <span style="mso-spacerun: yes">&nbsp;</span>and IF NOT (A) THEN B: Logically, this means that the conclusions should
 |
| always be true. This is symptomatic of the fact that the condition is really not relevant to the conclusion
 |
| </p><br />
 |
| <br /></sectionDescription> |
| </sections> |
| <sections xmi:id="_LmcIADmqEdy8N6BRpa8ByQ" name="Ensure completeness among rules" |
| guid="_LmcIADmqEdy8N6BRpa8ByQ"> |
| <sectionDescription><p class="MsoNormal" style="MARGIN: 3pt 0cm; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt">
 |
| We are often considering three kinds of completeness:
 |
| </p>
 |
| <div style="MARGIN-TOP: 0cm; MARGIN-LEFT: 2em" type="disc">
 |
| <ul style="MARGIN-TOP: 0cm" type="disc">
 |
| <li class="MsoNormal" style="MARGIN: 3pt 0cm; mso-list: l0 level2 lfo1; tab-stops: list 72.0pt">
 |
| Make sure that all the possibilities are covered for a given rule pattern. If you have a rule that says "loans
 |
| for value greater than 250,000 $ should be approved by the branch manager", it does not tell us who must/can
 |
| approve loans of value less than 250,000 $
 |
| </li>
 |
| <li class="MsoNormal" style="MARGIN: 3pt 0cm; mso-list: l0 level2 lfo1; tab-stops: list 72.0pt">
 |
| Make sure that all derived data in the object model has corresponding computation or inference rules. This
 |
| involves computed attributes, qualifications (e.g. customer status, account type, etc.)
 |
| </li>
 |
| <li class="MsoNormal" style="MARGIN: 3pt 0cm; mso-list: l0 level2 lfo1; tab-stops: list 72.0pt">
 |
| Make sure that integrity and cardinality constraints are somehow represented. Either in the object model or in
 |
| rules
 |
| </li>
 |
| </ul>
 |
| </div></sectionDescription> |
| </sections> |
| <sections xmi:id="_w3cyUDmoEdy8N6BRpa8ByQ" name="Analyze rule volatility" guid="_w3cyUDmoEdy8N6BRpa8ByQ"> |
| <sectionDescription><span
 |
| style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">This
 |
| a good timing to ask the business user how often the rule will change once we did the rule transformation.</span></sectionDescription> |
| </sections> |
| <sections xmi:id="_0-T6ADmoEdy8N6BRpa8ByQ" name="Understand rule dependencies, rule sharing" |
| guid="_0-T6ADmoEdy8N6BRpa8ByQ"> |
| <sectionDescription><p class="MsoNormal" style="MARGIN: 3pt 0cm; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt">
 |
| A rule R1 depends on a rule R2 if the enforcement of R2 results into a situation where R1 is relevant (or needs to be
 |
| enforced). A simple common example, is a rule R2 which is creating new data, or is modifying existing data that is
 |
| tested by R1.
 |
| </p><br class="MsoNormal" style="MARGIN: 3pt 0cm; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt" />
 |
| <br />
 |
| <p class="MsoNormal" style="MARGIN: 3pt 0cm; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt">
 |
| Understanding dependencies help determine the likely "execution" sequence of rules. The execution sequence is useful
 |
| for rule analysis to detect undesirable dependencies to plan rule testing. For the implementation the execution
 |
| sequence is useful to understand how the results will look like: some rule engine tools&nbsp;will determine that
 |
| sequence automatically, and on the fly (chaining). If we implement business rules in a procedural fashion, we need to
 |
| understand the execution sequence to enforce it
 |
| </p>
 |
| <p class="MsoNormal" style="MARGIN: 3pt 0cm; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt">
 |
| <span lang="EN-CA" style="mso-ansi-language: EN-CA">Some of the undesirable dependencies include circular dependencies
 |
| leading to infinite loops. Others will cause us to re-evaluate rule jurisdiction</span>
 |
| </p><br class="MsoNormal" style="MARGIN: 3pt 0cm; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt" />
 |
| <br />
 |
| <p class="MsoNormal" style="MARGIN: 3pt 0cm; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt">
 |
| <span lang="EN-CA" style="mso-ansi-language: EN-CA">When the work is done the last step is to look at how rule can be
 |
| shared between process flow. Rule sharing is an important step of the analysis. It can be done once we have progressed
 |
| in the rule set implementation. Rule re-factoring activity can help on implementing some rule sharing pattern.</span>
 |
| </p></sectionDescription> |
| </sections> |
| <purpose><p class="MsoNormal" style="MARGIN: 3pt 0cm">
 |
| The goal of the this task is to transform the rule in an artifact the business user can understand, and rule writer can
 |
| understand, implement, test and maintain.
 |
| </p></purpose> |
| </org.eclipse.epf.uma:TaskDescription> |
