|
Behavior and restriction rules can be entered
in USoft Developer in a non-procedural fashion. They are called
constraints in the repository and are stated in SQL. Defining
business rules as constraints is a very efficient way to develop
applications, for several reasons:
|
·
|
Atomic definition of the rule. |
The rules are entered
individually, and it is up to the Rules Engine to ensure that rules
are evaluated in the right sequence and combination.
|
·
|
Limited dependency on the time at which the business rule
should be evaluated. |
Normal programming requires
one to keep in mind the evaluation of the business rules at any
possible moment. There is code for pre-update, post-update,
pre-delete, and so on. This leads to various software replicas of
the business rules (that each need to be written, tested, and can
differ). The Rules Engine takes care of this itself; it is only
necessary to state what is not allowed, or what is to happen in a
certain situation, regardless of how the situation evolves.
|
·
|
The business rule can be translated into constraints regardless
of the context or order in which data is manipulated. Usually there
are many situations in which a rule can be evaluated. Take, for
example, a rule that calculates the price of an order. This
calculation becomes incorrect if, for example: |
|
·
|
A new order line is added or deleted. |
|
·
|
The quantity in an order line is updated. |
|
·
|
The article price is updated. |
|
·
|
The order's discount percentage is changed. |
All of these situations are
covered automatically by the business Rules Engine, independently
of the sequence in which the users UPDATE, INSERT, or DELETE.
The resulting situation is an
extremely clear single point of definition. The programming, and
therefore maintenance, is reduced to business rules definitions,
stating:
|
·
|
What should happen in certain situations? |
|
·
|
What is not allowed to
happen to the information? |
|
