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