Course Overview Topic 3

1
Course Overview - Topic 3

• Business Rules (BRs)
• Introduction to BRs
• Developing BRs
• Hands on Developing BRs
• Integrating BRs and OO Programs with AOP
• Hands on Integrating BRs with JAsCo
• María Agustina Cibrán mcibran_at_vub.ac.be
• Maja DHondt mjdhondt_at_vub.ac.be

2
In this Course

• defining BRs at conceptual level
• developing BRs analysis
• developing BRs design and implementation
• different kinds of implementation/representation
  approaches for BRs

3
What Are BRs?

• Business Rule Group
• A business rule is a statement that defines or
  constrains some aspect of the business. It is
  intended to assert business structure or to
  control or influence the behavior of the
  business. The business rules which concern the
  project are atomic - that is, they cannot be
  broken down further.
• ? business rules represent decisions, advice,
  recommendations, policies, preferences,

4
Where Do We Find BRs?

• many domains and businesses...
• insurance (health, travel, car, ) claims
  processing, billing,
• banking loan recommendation, fraud detection,
  personalised investments, customer relationships
  management,
• manufacturing resource optimization, inventory
  management, order fulfillment, logistical costs,
  coordination between manufacturing and the supply
  chain,
• government compliance with legislation and
  regulations
• e-commerce (car rental, online shop, )

5
Examples of BRs in e-Commerce (1)
6
Examples of BRs in e-Commerce (2)

• recommendations
• availabilities of products
• delivery rates
• delivery restrictions
• lead time to place an order
• refunds
• returns
• cancelling orders
• creditworthiness, trustworthiness, and
  authorisation

7
Kinds of BRs
Book on BRs Business Rules Applied by Barbara
von Halle and Defining Business Rules by the
Business Rule Group

• terms
• concepts, e.g. customer
• property of concept, e.g. status of customer
• constant, e.g. female
• facts
• connect terms, e.g. status of customer is gold
• rules
• discover new information
• decide to take action

8
Classification of Rules
At a business event, rules may be injected to
control its execution.
rule
constrains information
enables other action
creates new information
constraints
guidelines
action enabler rules
computations
inferences
9
Constraints

• constraints A constraint is a mandatory
  restriction on a business event, e.g.
• a customer must not purchase more than 25
  products at one time
• guidelines A guideline expresses a warning about
  a business event, e.g.
• a customer should not have more than 10 open
  orders at one time

10
Action Enablers

• An action enabler rule checks conditions at a
  business event and upon finding them true
  performs an action
• IF ltrelationgt(ltterm1gt,,termpgt) AND
• THEN ltactiongt
• if the status of a customer is gold, then give a
  15 discount on his or her order

11
Inferences

• An inference checks conditions at a business
  event and upon finding them true establishes the
  truth of a new fact
• IF ltrelationgt(ltterm1gt,,termpgt) AND
• THEN ltrelationgt(ltterm1gt,,termqgt)
• if a customer has purchased for more than 1000
  then he or she is a gold customer

12
Computations

• A computation provides a calculation on numeric
  data for arriving at a value for a term
• lttermgt IS COMPUTED AS ltformulagt
• the total price of an order IS COMPUTED BY
  subtracting a 15 discount from the subtotal

13
BRs Development Cycle

• discovery business conversation piece
• may not be relevant, atomic, declarative,
  reliable, precise, complete, unique, consistent
• ? natural language version
• is relevant, atomic, declarative, reliable
• but may not be precise, complete, unique,
  consistent
• analysis rule specification language version
• relevant, atomic, declarative, reliable, precise,
  complete, reliable, unique, consistent
• design depends on implementation medium
• implementation executable

14
BRs Development Criteria

• separate BRs from data and process
• do not put them in the database tier
• do not put them in the application tier
• do not put them in user interface tier
• ? put them in separate BRs Layer
• in all phases of development cycle !
• Note that BRs can still be represented in DBMS
  or object-oriented language!!!

15
Analysis of BRs

• make each rule atomic
• remove redundant or overlapping rules
• resolve inconsistencies among rules

16
Atomic Rules

• each rule should represent one complete thought,
  so should not be decomposable
• do not allow ANDs in the conclusion of action
  enablers and inference rules, nor in constraints
  and guidelines, but decompose them into separate
  rules
• only allow minimal conditions
• do not allow ORs in the condition of action
  enablers and inference rules, but decompose them
  into separate rules

17
Unique Rules

• rules should be truly distinct and the rule set
  minimal
• look for rules that enable a common action or
  infer the same information, and resolve them
• look for rules that have conditions in common and
  make sure that their conclusions are distinct

18
Consistent Rules

• rules are inconsistent if
• they have equivalent conditions but contradictory
  conclusions
• they have equivalent conclusions but
  contradictory conditions

19
Design of BRs

• design of BRs depends on implementation medium of
  the BRs
• data-change-oriented systems
• service-oriented systems
• DBMS
• rule management tools
• rule object patterns
• Whatever the implementation medium, BRs
• should be represented separately and explicitly!

• Rule-Based
• System

? Object-Oriented ? Programming Language
20
Rule Object Pattern

• BRs explicitly represented as objects rule
  objects
• BRs are separated from other application
  functionality
• BRs are activated from other objects by sending
  messages to rule objects
• patterns are used to structure more sophisticated
  BRs

21
Simple Rule Object Pattern
applyRule(Object o) if assessor.evaluate(o)
then action.perform(o)
22
Simple Rule Object with Properties
applyRule(Dictionary d) if
assessor.evaluate(d) then
action.perform(d)
23
Composite Assessors and Actions
24
Composite Rule Object
25
Rule Combination Strategies
26
Pros and Cons of Rule Objects

• no extra technology or language needed, just
  object-oriented programming language
• rules are easily activated by sending messages
• objects are not suitable abstraction for rules
• rule execution is naïve and not optimised
• rule combination is also expressed in objects and
  explicitly implemented

27
Rule Management Tools

• layer on top of object-oriented language for
  expressing rules more explicitly in IF THEN
  syntax
• rules are executed in object-oriented language
• examples Business Rule Beans from IBM, OptimalJ

28
DBMS

• rules are implemented as stored procedures or as
  triggers or other DBMS-specific features
• rules are fired when transactions occur on data
  to which the rules are related, e.g if a new row
  is added to the Customer table then all rules
  related to this table are triggered
• not discussed in this course

29
Pros and Cons of Rules in DBMS

• no extra technology or language needed, just DBMS
• rules are easily activated by triggers or stored
  procedures
• rules are hidden in DBMS, not reusable in other
  applications with other DBMSs
• rule execution is naïve and not optimised
• rule combination is also expressed in DBMS and
  explicitly implemented

30
Service-Oriented vs Data-Change-Oriented

• rule objects are activated when certain event
  occurs in application functionality
• ? service-oriented
• rules in DBMS are activated when certain data is
  created, changed or deleted
• ? data-change-oriented

31
Rule-Based Systems (1)

• an explicit construct is provided in the rule
  language for representing each rule - also
  referred to as a rule
• typically, rule have the IF THEN format
• rules use data in conditions and conclusions (or
  actions)
• a rule engine selects applicable rules and fires
  (activates) them

32
Rule-Based Systems (2)

• support for combination of rules is provided
• assigning priorities to rules
• meta-rules for specifying combination strategies
• built-in strategies in rule engine
• typically tools are provided for expressing rules
  in structured natural language, which is
  automatically transformed to rules in the rule
  language

33
Data-Change-Oriented Rule Systems (1)

• design and implementation are data-centric
• first define data or object model
• then attach rules to data or objects
• rules refer to and manipulate data or objects
• execution is also data-centric
• if data or objects are changed by running
  application or in conclusions (actions) of rules,
  then rule engine fires attached rules
• this can again result in data changes, which
  again activates the rule engine

34
Data-Change-Oriented Rule Systems (2)
examples Versata, USoft, R,
35
Data-Change-Oriented Rule Systems (3)

• sequence in which rules are executed is
  determined by sequence in which information is
  processed by the application, because
  user-application interactions correlate to data
  changes and with which rules are associated
• use data-change-oriented rule system when
  business event
• has short life cycle input - few interactions -
  database update
• is data-intensive

36
Service-Oriented Rule Systems (1)

• design and implementation are process-centric
• determine places in process or application
  functionality where rules are activated
• object model is only used to communicate data to
  the rules
• execution is also process-centric
• rule set is activated when certain object
  behaviour is being executed in method
• rule engine determines applicable rules in rule
  set and activates them, this can result in or
  require other rules being activated

37
Service-Oriented Rule Systems (2)
38
Service-Oriented Rule Systems(3)

• examples
• based on production rules OPSJ, JRules,
  QuickRules, Eclipse (Haley), Blaze, Jess,
• based on Prolog SOUL, NéOpus, K-Prolog,
  B-Prolog, Prolog Café, Jinni, InterProlog,
  JavaLog,

39
Service-Oriented Rule Systems (4)

• rules are executed upon request by a running
  application, not because it changes data
• data is passed to the rule system
• sequence in which rules are executed is
  determined by the rule engine
• use service-oriented rule system when business
  event
• represents entire sub task of application
• is rule-intensive

40
Conclusions (1)

• there are a few books on methodologies for
  developing object-oriented applications with
  explicit BRs (discovery, analysis, design,
  implementation, evolution, )
• there are MANY different representations for BRs
  (design patterns, OO tools, DBMS, rule-based
  systems) ? decide which one is suitable for kind
  of BRs in application

41
Conclusions (2)

• all representation approaches try to separate BRs
  from the application functionality, typically
  implemented in object-oriented language
• BUT in service-oriented approaches (rule
  objects, service-oriented rule systems) there is
  integration code TANGLED in the application
  functionality ? ASPECTS (see next course)

42
Exercises

• low-tech approach implement BRs as rule objects
• exercise in object-oriented programming, design
  patterns and Java
• next exercises integrate rule objects with
  e-commerce application using JAsCo