2. Decision design during Service Lifecycle
∗ Use business rule modeling tools in WODM to build
complex decision services.
∗ Gather all of the necessary pieces of information to:
∗ Make the decision
∗ Decompose the overall decision process into a set or
organized subtasks.
∗ Define each subtasks a set of business rules.
3. Identify business decisions
∗ Action verbs, such as determine, check, calculate, evaluate, decide,
and so on, that are applied to business objects typically indicate the
potential for a decision point.
∗ Validate quote request data.
∗ Determine driver eligibility.
∗ Compute quote pricing.
4. Defining the domain of discourse for the rules
∗ After the set of decision point is decided and before creating a rule project, firstly identify
conceptual object model for representing decisional context information and capture the
decision response while harvesting initial business rules.
∗ Conceptual object models accommodates
two characteristics:
∗ Cover all the details needed to make
the decision
∗ while staying understandable to the
business users.
UML Class Diagram
5. Tailoring the model for the business users
∗ After a first workable version of the conceptual model is available, it can be transformed into an
execution Object Model(XOM).
∗ The XOM represents the model of the data that is passed to the decision when it is executed.
∗ The rules are applied to this model. ∗ A Business Object
Model (BOM) is built on
Rule Designer top of XOM.
∗ A BOM associating
verbalizations with
classes, attributes, and
methods is intuitive for
the business users.
A BOM class
structure
6. Sharing a common model across decisions
∗ Setup a common rule project without rules for making
a sharable BOM.
∗ Other rule projects reference to this shared rule project.
∗ According to decision needs, the inheretant rule projects
can mask irrelevant information of parent rule project.
7. Establishing the decision signature
∗ After the BOMs is defined, the decision signature is established by
defining the interface of the decision to the outside world.
∗ Define what data a decision need as input and what data a decision
returns as the output.
These type
information are
drawn from a
BOM.
8. Decomposing the decision and orchestrating the subtasks
∗ A complex decision is composed of multiple subtasks.
∗ Decompose decision into subtasks and organize the sequence/flow of the
subtasks.
∗ Each subtask is usually a group of rules.
∗ Eligibility decision performs a group of validations: driver’s age
, driver’s perceived risk, and driver’s profile.
A rule package
∗ Place the functional group
s of rules into a sequence
using a rule flow.
9. Authoring business rules by business users in Decision Server
∗ The business rules are written to recognize a pattern in the context of
information provided to the decision.
∗ A set of actions is triggered when the rule conditions are satisfied.
Simple if-then-else
rule expression
Decision table
encompasses
multiple rules
sharing a template
of conditions and
actions
10. Decision integration
∗ Package up all
decisions in a rule
project and then
deploy to Rule
Execution Server.
∗ A common way to
expose a decision to
potential clients is
through a decision
web services.
