Transcript A Step out of the Ivory Tower to Business Rules Silvie Spreeuwenberg

A Step out of the Ivory Tower
Experiences with Adapting a Test Case Generation Idea
to Business Rules
Rainer Knauf
Technical University of Ilmenau
School of Computer Science
and Automation
Ilmenau, Germany
Silvie Spreeuwenberg
Rik Gerrits
LibRT B.V.
Amsterdam, The Netherlands
Martin Jendreck
reinisch AG
Karlsruhe, Germany
A Step out of the Ivory Tower - Experiences with Generating Test Cases for Business Rules
1
Content
1. Motivation
2. A Closer Look at Business Rules
 The Representation Aspect
 The Processing Aspect
3. The Application Scenario to Perform Evaluation
 The Entire Framework
 The Part Implemented for AionBRE
 The Architecture of the Complete Evaluation Module
 The Technology to Generate QuEST
4. Particular Problems of this Technology Transfer
 Dependencies of Outputs
 Critical Input Values and Appropriate Ranges
 Computing Potential test case values
 Composing Test Data
 Minimizing Test data
5. Summary and Outlook
A Step out of the Ivory Tower - Experiences with Generating Test Cases for Business Rules
2
What are Business Rules?
 Knowledge representation in commercial environments
What are they used for?
 Describing business functions in descriptive manner
 Supporting decision making in commercial environments
What are the application fields?
 The upcoming European Business Rule Conference (June 2004,
Amsterdam) covers contributions about applications in











E-government that aims at improving the government to citizen (G2C) and
government to business (G2B) interaction (NL)
Risk analyses of financial institutions (D)
Pharmacy (NL)
Personnel regulations for central government personnel (B)
Security management in banking (CH)
Monitoring economic and technical performance of the Dutch agriculture (NL)
Construction of the new Metro Railway in Amsterdam (NL)
A Business Rules Based Portal for Healthy Living (NL)
Marketing in grocery industry (A, I)
Automated order management for the retail business at Swisscom (CH)
Insurance and healthcare case studies (UK)
A Step out of the Ivory Tower - Experiences with Generating Test Cases for Business Rules
3
What kinds of Business Rules are distinguished?
1.
Rules that describe constraints (= knowledge representation rules)
2.
Rules that describe derivations (= knowledge processing rules)
What are they formally ?

Basically, HORN clauses with attribute-value pairs as their atomic
components

Concrete BR languages provide much more expressiveness that is far
beyond a logic or any other formal calculus, such as

function calls

equations and in-equations with arithmetic terms,

calls of methods,

…
– That’s
the challenge!
A Step out of the Ivory Tower - Experiences with Generating Test Cases for Business Rules
4
Why and how to evaluate such rule bases?

The usefulness of this approach corresponds to the correctness of its
incorporated rule base.
1.
The need of formal verification is impressively shown by the selling
success of LibRT’s product VALENS™, a verification tool for BR that
reveals several kinds of
2.

Contradictions

Redundancies

Completeness (of value ranges, e.g.)

Unused conclusions

Loops

Self-contradicting rule premises

Unreachable conclusions

…
The need of validation is indicated by LibRT’s request to complete their
evaluation tool by a validation method like our one
A Step out of the Ivory Tower - Experiences with Generating Test Cases for Business Rules
5
2 A Closer look at BR
According to their purpose (control of business courses), BR appear in
different forms (that are not necessarily rules from our viewpoint):
1. definition of business terminologies
… by glossaries, entities of an ERM, description logic of an ontology
2. facts express relations between terminologies
… by a graph or natural language statements
3. instructions and restrictions control the access to business data
… by “real rules” IF … THEN …
4. derivations define the way to infer new knowledge
… by computation rules and inference rules
This large variety of formal, semi-formal and informal knowledge
representations is not an appropriate subject for AI technologies
 formal sub-languages have been developed, for example
CleverPath Aion Business Rules Expert™ ( AionBRE )
A Step out of the Ivory Tower - Experiences with Generating Test Cases for Business Rules
6
AionBRE
1.
Knowledge Representation
proposition calculus’ HORN clauses with an extended expressiveness:
atomic formulas are not limited to logic statements, but
 as premises

attribute-value pairs

equations and in-equations with attributes, values, arithmetic terms on both
sides

function calls

calls of methods
 as conclusions

attribute-value assignments

calls of methods
2.
Knowledge Processing
Takes place at two levels:
1. by choosing built-in inference methods like

forward or backward chaining

inheritance within a class hierarchy

truth maintenance assignments
2. by user defined inference rules like

pattern matching rules

event rules
A Step out of the Ivory Tower - Experiences with Generating Test Cases for Business Rules
7
3
Validation Scenario
3.1 The Entire Framework
TURING Test
validators
refined (better)
knowledge base
criteria
rules
knowledge
base
+outputs
test case
generation
test data
test case experimentation
+solutions
protocol
system
refinement
validity
statements
validity
assessment
evaluation
report
system user
knowledge engineer
A Step out of the Ivory Tower - Experiences with Generating Test Cases for Business Rules
8
3.2 The Part Implemented for AionBRE
test case generation
expert(s)
criteria
rule
base
knowledge
base
initial
test case
generation
QuEST
ReST
reduction
test
case
experimentation
QuESTer
A Step out of the Ivory Tower - Experiences with Generating Test Cases for Business Rules
9
3.3 The Architecture of the Complete Evaluation Module
 number of
computed
potential test
cases
rules
Rule base
XML
as rule base
XML schema
 rules
 all final
conclusions
VALENS
 number of
computed test
data that infer
an output
 QuEST and its
cardinality
 test data
 their
outputs
 hints to rule
base
anomalies
QuESTer
A Step out of the Ivory Tower - Experiences with Generating Test Cases for Business Rules
10
3.4 The Technology to generate QuEST
rule set R
Computation of dependency sets
Dependencies
Ri : R  oi
Si : S  oi
Computation of critical values & scanning distances
Critical values & Scanning distances
Skcrit  values( sk )
sk = subrange( sk )
Computation of potential test data values
Test data values of sj for oi
Vij = f( oi , sj )  values( sj )
Composing the set of potential test data
Composed test data set for all oi
P =  ( Vi1  Vi2  ...  Vim ) =   Vij
n
n
m
i=1
i=1
j=1
Minimizing the set of potential test data
oi - related partition of P & minimized Pi -s
Composed QuEST
Pi = f( oi )  P
n
QuEST =
P i*  P i
 { [ ti , oi ] :
i=1
t i  P i* }
test case set QuEST
A Step out of the Ivory Tower - Experiences with Generating Test Cases for Business Rules
11
4
Particular Problems in Implementing this Idea (Problem / Solution)
4.1 Dependencies of Outputs
Misunderstanding # 1
What is an „output“?
(1) A single expression of the proposition calculus or
(2) a „written attribute“ that can be assigned to a particular value?
The BR community prefers the 2nd definition; we assumed the 1th one.
In a first setting, we adopted definition (2).
 Since the number of used attribute values is usually a tiny subset of the
complete rage, definition (2) increases the resulting number of test cases
dramatically:
An example with just two short rules revealed 15 test cases underlying definition # 2
versus 7 cases by underlying definition # 1.

Thus, later (when implementing the minimizing procedure) we turned back to
our understanding of an output and considered an attribute-value pair as an
output, that follows our intention of being a single statement.
A Step out of the Ivory Tower - Experiences with Generating Test Cases for Business Rules
12
Misunderstanding # 2
What is a „rule“?
(1) An „IF-THEN“ construction with logic elements that can be true or false or
(2) An „IF-THEN“ construction that also includes function and/or method calls in
the IF-part as well as method calls in the THEN-part?
The BR community uses the 2nd definition; we assumed the 1st one.

To adapt our technology to practical needs (as claimed by the BR
community), we adopted definition (2) and „normalized“ the rule bases to
equivalent ones, which follows definition (1):



A rule that contains function calls in the IF-part is „recompiled“ to several rules
according to the possible values of the function call.
A rule that contains method calls, is not really a problem as long as the methods
do not have any access to the rule set itself. Following the HORN logic, these calls
could be considered as logically true in the IF-part respectively false in the THENpart.
This raised some restrictions of the technology‘s applicability:

„Meta-logic“ rules, which‘s use depend on rules or even change rules,
have to be forbidden. Thus, we excluded method calls doing that.
A Step out of the Ivory Tower - Experiences with Generating Test Cases for Business Rules
13
Misunderstanding # 3
What is the logical structure of a „rule“?
(1) A rule is
 a HORN clause like
A

 or at least a clause like
A1  …  Am

(2) A rule can also have conjunctive conclusions, i.e.
 a construction like
A1  …  Am

B1  …  Bn
B1  …  Bn
B1  …  Bn
The BR community allows the 2nd definition as well.

To adapt our technology to practical need of the 2nd rule structure, we
adopted definition (2) and „normalized“ the rule bases to equivalent ones.
This could be performed by substituting rules of this structure by several
ones with alternative THEN-parts:
m
B
j 1
n
j
  Ai
í 1
n
n
í 1
í 1
 ( B1   Ai )  ...  ( Bm   Ai )
A Step out of the Ivory Tower - Experiences with Generating Test Cases for Business Rules
14
4.2 Critical Values and Scanning Distances
Here, we compute
1. critical input values, which mark a difference with the effect on an output and
2. scanning distances, which define, how close the test cases should be located
to these critical values.
Problems solved:
1. Additional data types needed to be introduced to AionBRE:

Enumerable data (of the type string, integer, and real) needed to be
distinguished in those with / without an inherent ordering relation.
2. Several type conflicts are managed.

For example, if two inputs of different types (real and integer, e.g.) are
compared the computed critical values and scanning distances need to
be rounded up or down to some „closest valid value“.
3. The approach was extended to consider input data with several disjunctive
ranges by adapting the computation of scanning values.
4. „Smallest possible steps“ needed to be defined for integers (= 1) and reals
(by considering the way AionBRE handles fractions).
Problem left as a restriction of the applicability (yet):
 Outputs, which refer to input values.
But It should be easy to solve it by some „normalization“.
A Step out of the Ivory Tower - Experiences with Generating Test Cases for Business Rules
15
4.3 Computing Test Data Values
Here, the interesting values Vij for an input si for an output oj is computed.
In case si does not influence oj, some arbitrary (normal) value is introduced in Vij.
This did not raise a problem, but an idea to refine the technology:

This arbitrary value is determined in a way that supports the minimality of the
test case set: We choose a value si that is a test case value for another
output ok.
4.4 Composing Complete Test Data
… could be implemented to AionBRE without any problem.
A Step out of the Ivory Tower - Experiences with Generating Test Cases for Business Rules
16
4.5 Minimizing the Set of Test Data
The solution for „misunderstanding # 1“ in section 4.1 has been developed here.
Furthermore, the implementation of this step led to a refinement of the approach:
The approach is based on
1. forming partitionings of test data into subsets, in which the elements differ from
each other in just one input value and
2. looking for values of this input, which are subsumed by other values.


Since the test data are minimized for each output separately, input values that
don‘t influence this output don‘t have to be considered while forming
partitionings.
This increased the sets and thus, the chances for such subsumptions,
significantly.
If there are several chances to define test data that subsumes other ones,
some optimization has been introduced:
The test data, which can serve as test data for as many as possible other
outputs as well, is preferred.
A Step out of the Ivory Tower - Experiences with Generating Test Cases for Business Rules
17
Short Summary
1.
Implementing theoretical Ideas into commercial environments reveals
problems far away from the imagination of developers working in an scientific
environment – an Ivory Tower.
2.
Fist of all, a common terminology needs to be agreed.
3.
The main challenge was the „trade-off“ between logic approaches and the
desired involvement of software technologies that can not be handled logically.
4.
The performed technology transfer turned out to be a chance to

identify problems that haven‘t considered before and to

identify refinements and improvements of the theoretic ideas developed
in the „Ivory Tower“.
A Step out of the Ivory Tower - Experiences with Generating Test Cases for Business Rules
18