Business rules – an introduction
This booklet is published under
the terms of the licence summarized in footnote 1.
This booklet contains a collection of RAP Group papers that discuss ways to specify the business rules of automated business services in a service-oriented enterprise application.
A rule classification from the Business Rule Group
Housing business rules in an entity-event model
More about Terms, Facts, Constraints and Derivations
Preface
This booklet is about the analysis and specification work that is needed to pin down exactly what a system will do for users by way of evaluating and enforcing business rules. (When we say “rule”, you can read “business rule”.)
What kind of system?
Here, a system is a data processing system that supports, monitors and to some extent controls a business activity system.
Most architecture frameworks, most analysis and design methods, are rooted in techniques for data processing system analysis and design. They expect architects and/or analysts to model data and processes in way that reflects those entities and events in a business activity system that the business wants to monitor, and to some extent control.
We expect to use computers for data processing (all computers can do is push and pull data). We do expect specified rules to be implemented in software. But the same rules can be applied by any kind of data processing system.
The table below is not intended to be a formal classification of activity systems. It is only a device to show that data processing is not always performed by software. So, a truly technology-independent specification of data processing stands above any decision about whether computers are used or not, let alone any choice of programming language.
|
Biological systems |
Human activity systems |
Clerical data processing systems |
|
Goods and service production systems |
||
|
Social systems |
||
|
Other kinds of biological systems |
|
|
|
Technological systems |
Computer software systems |
Software data processing systems |
|
Other kinds of software system |
||
|
Electro-mechanical systems |
Electro-mechanical data processing systems |
|
|
Other kinds of electro-mechanical system |
||
|
Other kinds of technological systems |
|
The first of our principles is this:
|
A software system
principle |
A software system
can do nothing for a business but recognise and produce data flows; it
validates input data events, stores the state of persistent data entities, and
derives output from the input and state data. |
What kind of rule?
Here, a rule is a directive and functional requirement (rather than a non-functional requirement like response time) that defines some part of the semantics of a system.
· Semantics: what external actors understand of how a system constrains their behavior and what the system does for them. This understanding is expressable in the form rules.
· Rule: a directive statement about system structure or behaviour that an external actor understands or finds useful to its purposes, specifiable through the preconditions and post conditions of transient events and the invariant conditions of persistent entities.
There are other definitions. The Object Management Group’s Business Motivation Model contains these definitions.
|
Policy |
“A rule
that governs or guides the strategy” |
|
Business Rule |
“An
actionable rule derived from the policy” “A statement that
defines or constrains some aspect of the business. It is intended to assert the
policy or structure of a business, or to control or influence the behavior of
the business.” |
However, the terms used in this booklet are closer to the definitions of the Information Systems Examination Board (ISEB), in which Principles (as in TOGAF) appear at the top level of a three-level hierarchy.
|
Principle |
A
directive at the top of the directive hierarchy. A strategic, abstract and
not-directly-actionable directive that derives from high-level goals. A
statement of an outcome that reflects goals. A tool used in governance of
architecture work. Principles can be related to business, data, applications,
infrastructure or security. E.g.
|
|
Policy |
A directive
in middle of the directive hierarchy. A tactical directive that derives from
objectives. A tool used in governance of day to day work. It guides behavior
that the company expects will lead to desired outcomes. e.g. Members
of the public have minimal access to data.
|
|
Business Rule |
A
directive at the bottom of the directive hierarchy. It directs and constrains
a procedure. It appears in specifications of automated data processing. A Term,
Fact, Constraint or Derivation Rule used in definition of data processing.
e.g.
|
How do business people express rules?
Some discuss rules in a way that is independent of any data processing system – in a conceptual model of business terms. Some suggest building a rules catalogue at this level.
You can of course give each rule a unique
identifier and fill a rules catalogue with rules. This
table below catalogues some examples (published by Ron Ross) of rules expressed
by business people.
|
Id |
A catalogue
of concept-level business rules |
|
1 |
“A group must not include any union members if it includes any non-union members, and vice versa.” |
|
2 |
“A poor-risk
customer must not place a rush Order ” |
|
3 |
“An employee’s
new salary must be greater than or equal to the employee’s current salary.” |
|
4 |
“A truck
carrying hazardous material must not be routed through a downtown street.” |
|
5 |
“A trainee must
not send a memo to a manager without permission of his supervisor.” |
|
6 |
“A person must
be considered a woman, if the person is female and is over 21.” |
(Notice how often the
word ‘not’ features in these examples, because these are mostly “constraints”.
A constraint is a rule designed to prevent a process happening if the rule is
not met.)
For us, this is a catalogue of policies - or conceptual-level rules - awaiting analysis and transformation into statements housed in a logical model of a data processing system.
Building a catalogue of principles, policies and informal rules is a good start, but it is not enough to specify a coherent data processing system without ambiguity. Few enterprises maintain a rules catalogue that is unrelated to the data processing systems that impose those rules. The quality of the catalogue will be proportional its usage. And its usage is usually in the logical specification of software systems.
Discussing business policies and rules with business people is good. Cataloguing what they say is good. But a software developer does not know what to do with a rules catalogue. As a correspondent (name lost) told me:
“you can write direction-less business rules at
a business level independently of any system.
For example: Order Value = Order Amount * ProductPrice when Order Amount
< 100.
But to use those rules in a system specification you will rewrite the
rules with a particular direction based on the scope and purpose of the
business components.
For example you can use the above rule in several ways to.
·
derive
a value for Order Value from other stored data
·
test
whether a user-entered Order Value meets all constraints
·
conclude
that if Order Amount => 100 then Order Value <> Order Amount *
ProductPrice
·
derive
"ProductPrice" based on Order Value and Order Amount” anon
Analysts have to analyse what they are told by
business people. They must make sure the rules are comprehensive and
consistent. They must specify
entities and events in an unambiguous way that helps software developers to
code process and data definitions.
Why declare business rules in a model?
Rules on their own are
little use. It is important to embed rules in coherent logical model of a
system, because this helps you to:
·
express
rules without ambiguity
·
spot
duplicate or conflicting rules
·
spot
where a supposedly invariant rule in fact differs between services
·
optimise (reuse) rules.
Moreover, the effort to create a coherent model will reveal more rules, and lead to changes in those already documented.
You might build a rules model for any of several reasons:
·
to
facilitate discussions with business people and clarify requirements
·
to
refine a higher-level conceptual or business model into data processing terms
·
to
facilitate discussions with software developers
·
to
specify software programs or clerical procedures
·
to specify database structures.
Trying to meet all of these goals in one model creates some tensions, which are reviewed in this and related booklets.
Analysts are rarely taught how to capture rules in models
of entities and events. So this booklet can be of immediate help to
anybody specifying enterprise applications.
How is this related to service-oriented architecture (SOA)?
The quality and
integrity of business data is vital to business processes. The information supplied to business people must accurately reflect
the state of world the enterprise operates in. The enterprise’s stored business
data should be consistent with all business rules.
The principle of service-orientation leads designers to encapsulate business data behind a façade of automated services.
|
Principle |
Service-orientation
|
|
Statement |
Define a system is primarily by the external services it offers (and only secondarily by its internal components). Define each service by a contract including its signature, semantics (or rules) and non-functional requirements. |
|
Rationale |
Interoperability, portability and reuse are increased when analysts specify required services in a service catalogue, builders define provided services in a service directory, and efforts are made to match required services to provided services. |
|
Implications |
The enterprise must follow a consistent approach to system specification and implementation, centered on the governance of a service catalogue. |
Further, the principle of “defensive design” - the norm in enterprise application software – leads designers to code business rules in automated services.
|
Principle |
Defensive
design |
|
Statement |
An automated service must test all its preconditions before updating stored data according to other defined business rules. |
|
Rationale |
Prevent the corruption of data by clients who do not know the preconditions. |
|
Implications |
All the necessary rules are declared an event/service catalogue. |
So, many rules are naturally specified in an event/service catalogue. (The same rules may be executed at user interfaces, for usability and performance reasons, but that is not where they should be specified.)
Who models business rules?
The assumption in this booklet is that systems analysts should record rules in a structured narrative that a) all interested people can read, and b) software developers will find helpful as a specification.
The assumption implies two roles: systems analysts who write down rules and software developers who code them using a specific technology.
|
The analysis
principle |
Analysts find
things out, define activities in the business domain, distil a mess of data processing
requirements into discrete elements, and define essential business rules in a
semi-formal manner.. |
What if you are an agile analyst-programmer, who plays both these roles in your project? Should you still write down the rules alongside the code? That question is hotly debated between those who favor model-driven development and those who don’t.
We don’t believe programming languages will ever provide a suitable form for discussion and analysis of rules. We have to write rules down in a form that is more human-friendly, yet also associated with a model that can be turned into software.
Niche-market rules engine technologies have a place, but they are not a universal solution. Systems analysts want a consistent approach to specification that will work in every situation. They do not care whether the software will be written in a procedural or OO programming style or language. They want to say nothing that is technology-dependent.
Systems analysts want:
·
techniques
for analysing rules
·
forms
and diagrams for recording rules
·
to
record rules in a form that is close to natural language
·
to
record rules in a way that is entirely platform-independent (that is,
independent of programming paradigm, development framework, database management
system and any other computing technology)
·
to
communicate rules that without dictating
the design or modularisation of software
Software developers want systems analysts to work
this way. They don’t want to be given pseudo-code, or specifications written in
formal languages, and they don’t want the analyst to prejudice design decisions
about how to modularise the software.
Having said all that, systems analysts do have to understand and consider some physical design constraints as well as logical concerns. Above all, they must understand the distribution of the persistent data between discrete data stores, and the scope of a roll-backable transaction.
Must we completely document all rules?
No. Our approach is to specify rules in a
methodical and semi-formal way that software developers can use. But we don’t
propose that you have to document every trivial rule. How far you need to
complete a model is a question to be asked and answered afresh in each
situation.
|
The analysis
principle 2 |
Analysts do not write
software – and do not complete all data and process models to the bottom
level of detail and precision that would be required for code generation. |
How to document business rules?
We don’t lack for ways to document rules. Rather, we have too many of them. If we use all of them, we end up specifying the same rules many times over. And some techniques are far too formal and elaborate for ordinary systems analysts to use.
Our approach is related to, yet also different from, other approaches to the analysis and specification of rules.
Perhaps the easiest way to introduce rules is by illustrating the four-way classification scheme developed by the Business Rules Group, using examples that systems analysts and software designers can readily relate to.
Terms
The terms used to declare rules are important.
The Business Rules Group long ago recognized that a rule statement has to be
expressed using a limited and well-defined vocabulary.
Consider these words:
Order , Order Placement, Order Amount and DeliveryDate.
You probably think of these as the names of data groups and data items. The ISEB reference model contains the following definition.
|
Data
item |
An elementary
unit of information, a fact about an entity or an event. An attribute of an entity in a data model
or an event in a data flow structure.
A variable containing a value that is constrained by a type. |
In rules analysis, business data item names are business <terms>, and they deserve careful definition in some kind of dictionary or model.
Facts
Consider this persistent entity and the attributes recorded with it:
Order (CustomerName, Order Id, ProductType, Order Amount, Order Value and Order DeliveryDate).
The attributes are <facts> about an Order that must be remembered (retained in persistent memory) if business processes are to work.
Consider this transient event and the arguments or parameters it carries:
Order Placement (CustomerName, ProductType, Order Amount and Order DeliveryDate).
The parameters are <facts> that identify which product a customer wants, how much product is wanted, and when it is wanted; they introduce these facts about a persistent Order entity into the system.
The ISEB reference model
does not mention facts, since they are implicit within documentation of
entities, attributes, relationships and events.
Constraints
Consider that an Order Amount is a number, and an Order Value is a currency amount. Both statements express a data type that acts as a <constraint> on the value of a data item. Consider also the rule that
Order Amount cannot be greater than ProductBalance.
This expresses a more elaborate constraint on a parameter of the Order Placement event. The event must be rejected if the stated precondition is not met.
The ISEB reference model
includes these relevant terms and definitions.
|
A
generalisation; a form or structure common to several things; a constraint on
an instance shared by all instance of that kind. |
|
|
Data
type |
A type
that defines the properties shared by instances of a data item or larger data
structure. It constrains the values of
the data. It defines the processes
that can legitimately be performed on the data. |
|
Data type
(primitive) |
A data
type defined in a programming language. e.g.
alphanumeric string, integer, floating-point number (decimal), and boolean. |
|
Data
type (user-defined) |
A data
type defined by systems analysts that is bespoke to the business at hand. e.g. customer, order, product. |
|
Constraint
(rule) |
A
business rule that further limits the values of a data type. |
Derivations
Consider the expression:
Order Value = Order Amount * ProductPrice.
This expression constrains Order Value at the time it is calculated . However, such a constraint, especially when it is the post condition of a process (or service as we know it), is more usually called a <derivation>.
The ISEB reference model includes this definition.
|
Derivation
rule |
A
business rule that defines how the value of a data item is derived from the
value of one or more other items (a special kind of constraint). |
Invariant and transient rules
After the specification of input and output data, the essence of software specification is the logic, the rules.
Computer scientists and software developers often approach the specification of rules with the idea that a process or service can be defined in a formal way by its preconditions and post conditions – along with invariant conditions.
·
Precondition: a
condition that must be true immediately before a service, for the service to
succeed.
·
Post
condition: a condition that must be true immediately
after a service.
·
Invariant: a
condition that applies to specified data forever (that is, until the data
specification is changed).
The table
below names an entity with one invariant, and two enquiry processes, each with
a pre condition and a post condition.
|
Entity |
Circle
Mathematics Component |
|
|
|
Pi = 3.14 |
|
|
Enquiries |
Preconditions |
Post
conditions |
|
Give me
circumference |
Radius is a
number |
Circumference =
(radius + radius) * Pi |
|
Give me area |
Radius is a
number |
Area = radius * radius
* Pi |
This declarative style of specification is often contrasted with a procedural style, in which the logic of the process is defined. We don’t rule out the need to specify logic in a procedural manner, but it is not the focus of this booklet.
Static and dynamic rules
The ISO-1982 report “Concepts and Terminology for
the Conceptual Schema and Information Base” distinguished static and dynamic
rules.
|
ISO rule type |
A static rule |
A dynamic rule |
|
|
“applies to each state of the information base,
taken individually.” |
“governs the evolution of the information base over
time and hence involves more than one state.” |
|
Example |
each Person has at most one Age, at most one MaritalStatus. |
Allowed changes in MaritalStatus are: ‘Single’ to ‘Married’; ‘Married’ to ‘Widowed’, etc. |
|
Our scheme |
Invariant rule in a structural or entity model |
Transient rule in a behavioral or event model |
The
static-dynamic division seems to,
and probably does, match the division between structural and behavioral rules
in our scheme.
Structural and behavioral
rules
The Business Rules Group define semantics as
being composed of terms, facts, constraints and derivations. In his book (ref.
2), Tony Morgan says that you are likely to come across structural
(entity-oriented) rules, behavioral (event or service-oriented) rules, and
definitional rules.
Tony Morgan was a member of the RAP group during
the time we extended the Business Rules Group scheme of terms, facts,
constraints and derivations by loosely
subdividing each kind of rule into structural and behavioral varieties, giving:
· Structural model terms, facts, constraints and derivations
· Behavioral (event or service-oriented) model terms, facts, constraints and derivations.
This subdivision indicates whether a rule belongs more naturally in the structural or the behavioral view of a system model.
This table shows a crude mapping between different rule classification schemes.
|
|
Structural rule |
Behavioral rule |
|
Constraint |
Invariant |
Precondition |
|
Derivation |
Invariant |
Post condition |
The table is a
simplification. Some post conditions are not derivations. Some preconditions
involve a derivation. A precondition that stipulate the types of the entities
that can participate in processing an event sounds like what we call a
behavioral fact.
Housing business rules in an entity-event model
Our approach (based on
techniques used in the
|
Three-dimensional entity-event model |
||
|
Entity-attribute-relationship view |
Entity life history view |
Event view |
|
Diagram types: a data model, or a class diagram. |
Diagram types: a state chart. |
Diagram types: an interaction diagram or an event impact structure. |
|
Tabular view: an entity-relationship table. a table for each entity, listing its attributes. |
Tabular view: a table that shows the effects of events on the entity type. |
Tabular view: a table that shows the effects of the event type on various entities. |
|
Structural
view |
Behavioural
views |
|
Later booklets illustrate diagram types mentioned in this table. However, it seems a good idea to specify rules in the simplest form that works without ambiguity. And this introductory booklet uses only tables to specify rules.
This booklet uses the terms entity and event. Strictly speaking, the ISEB reference model suggests we should say data entity and data event, since the reference model includes these relevant terms and definitions.
|
Entity |
A
structural thing that persists. A
thing that is created, affected and ultimately destroyed by events. |
|
Event |
A
behavioural thing that happens. May
create or destroy an entity, or move an entity from one state to another in
its lifecycle. May affect several entities. |
|
Data
entity |
The representation
of an entity as a data structure that persists in a data processing
system. Often corresponds to and
records the state of a business process. |
|
Data
event |
The
representation of an event as a data structure in a data flow input to one or
more data processing systems. |
|
Data
lifecycle |
The
life of a data entity ex |
This section discusses how rules can be documented from different perspectives, within one overall rules model.
The state of a system
The state of a system is sum of the states of
many discrete and persistent entities within the system boundary.
The state of a business process may be reflected in the state of a single persistent data entity, or a group of closely-related entities.
Rules describe the valid content of a bounded
system; they constrain the state of that system, and they constrain the flow of
business processes.
The state of a system is updated when a transient event happens. An event-triggered service implements the effects of an event; it refers to the state of one or more entities in the system, it can change the state of those entities and so change the state of the overall system.
An event is discrete and atomic. This means it is
considered to make an instantaneous change to the state of the whole system –
even though the process to make this change happen is composed of many small
actions, affecting many discrete entities within the system.
You cannot specify a rule properly without
referring to the entities that hold the state of the system and the events than
change the state of a system.
Three levels of model
The table below shows the rules model we are interested in sits somewhere between a universe of discourse and a software system.
|
Universe of discourse |
System users
and purchasers |
|
Analysts suppress irrelevant information from the discourse |
|
|
Rules model |
Systems analysts |
|
Analyst suppress details from the software |
|
|
Application software |
Designers and
builders |
We want to specify rules using terms that business people and users of the application should understand, because the system is a model of the things they want to monitor and perhaps control.
It is often recommended that people maintain models at three levels of idealisation from an operational system. The ISEB reference model includes these relevant definitions.
|
Idealisation hierarchy |
The idealisation hierarchy of
conceptual model, logical model and physical model. |
|
Conceptual (or domain) model |
A logical model that defines terms
and concepts in a business or problem domain without reference to any
computer application. In
MDA, a computation-independent model (CIM). |
|
Logical model |
A model that excludes details
of physical implementation. In MDA, a platform-independent
model (PIM) that is unrelated to a specific technology (though may be related
to a standard). |
|
Physical model |
A model that includes details
of physical implementation. In MDA, a platform-specific
model (PSM) that is related to a specific technology, and may include
specific infrastructure functions. |
It is possible to build a rules model at each level. At the top conceptual level, you can abstract from the many physical databases maintained by your enterprise, and build a rules model that disregards the physical distribution of your applications. You can specify rues against an enterprise-wide business data model – a notional data store rather than an actual physical data store. However, a conceptual model of this kind has to be much transformed in various ways before developers can use it. See the booklet <The Agile Enterprise> for further discussion.
Our main focus in these booklets is rules related to entities and events in a logical model.
|
Conceptual model |
Real world
entities |
Real world events |
Business
processes |
|
Logical model |
Data entities |
Data events |
Entity life
histories |
|
Physical model |
Entity objects
and database tables |
Control objects
and messages |
State constraints
on procedures |
A logical’ model is a technology or platform-independent model (PIM). It is an abstraction by idealisation from technology or platform-specific model (PSM). (See ref.1 for discussion of others kinds of abstraction.)
|
The PIM principle |
Analysts produce a logical
specification (a platform-independent model) that ignores the programming
paradigm and technology, but does take account of some physical design
constraints. |
There are three
points to remember about a middle-level logical model
· It is a model of data processing, which in turn is a model of real word entities and events.
· The scope of the model is the scope of a data processing system that maintains a coherent data store (in which all retrieved information should appear consistent to anybody who inspects it, even though the data may be distributed).
· The model usually specifies software. Whether this software is coded in an object-oriented or procedural style is of no importance.
The fact that analysts can define the model well enough to be a basis for software development is important because it sets a level of expectation about quality and level of detail.
The OMG's MDA is about automating the transformations between conceptual, logical and physical models (CIMs, PIMs and PSMs) people build to specify software systems.
|
Conceptual model |
CIM |
Computation-Independent Model |
|
Logical model |
PIM |
Platform-Independent Model |
|
Physical model |
PSM |
Platform-Specific Model |
Our entity and events models are rather
more logical model (PIM) tha conceptual model (CIM). Curiously, however, some
might call them conceptual, because they declare only the effects of events,
not the operations that implement those effects.
Three-dimensions of a model
To model the rules of an application we need a structural view, supported by behavioral views. Almost every modern applications development method, whether structured or object-oriented, offers a three-dimensional approach to modelling.
|
Structural model |
Behavioral models |
|
|
Entity-attribute-relationship view |
Entity life history view |
Event view |
|
Object-oriented views |
Event-oriented view |
|
The event views can be drawn as object interaction diagrams. These feature prominently in object-oriented design methods, but they cannot rightly be called object-oriented, since they show a system from the perspective of an event or a service.
|
The entity and
event principle |
Analysts treat
entity-oriented and event-oriented views of a system as complementary and
equally important, and unite them by specifying the effects of events on
entities. |
Different methods provide different graphical modelling notations for each view. Indeed, UML provides several alternative notations for one view. Some notations are shown in later booklets.
A three-level and three-dimensional framework
The table below is the RAP group modelling framework.
|
Orientation Level |
Structural
model |
Behavioral Models |
|
|
What |
When |
How |
|
|
Conceptual model |
Real world entities |
Business processes |
Real world events |
|
Logical model |
Data entities |
Entity life histories |
Data events |
|
Physical model |
Entity objects and database tables |
State constraints on procedures |
Control objects and services |
Our focus is on the level
of the logical model, and on specifying rules in models of data entities and
data events.
Structural models
The term structural model here covers various forms of specification: an entity-attribute-relationship model, a data model, a class diagram, or a database schema.
Structural analysis is probably the best established and most widely used of all application specification techniques. So knowing how to get a structural model right is important!
Structural analysis is at the heart of most application design methods. It is also the central technique in most object-oriented software design methods. Most upper CASE tools provide support the drawing of a structural model. Some lower CASE tools and visual programming environments can generate executable software from a structural model.
All these methods and tools expect the analyst to divide an application into classes of entities and specify the relationships between the classes. Classes, relationships, and simple multiplicity constraints on relationships can be shown in a diagram that looks something like the one shown below (using the CACI notation).
A structural model is useful from the start of analysis right through to design and implementation.
A
conceptual-level structural model describes the world outside of the
enterprise’s applications. While investigating a business application, analysts
may take the view that each box represents a type of business entity, and each
line represents a relationship that is meaningful in the business, regardless
of any software that might exist.
A logical-level structural model describes the essential concepts within the application. The viewpoint changes. You stop thinking of a box as representing a business entity and start considering it as representing a data entity – a group of data items representing facts about a thing. You stop thinking of a line as representing a real-world relationship and start considering it as representing a Structural constraint on how data is stored. However, you can still specify a model that is ‘logical’ in sense of being entirely independent of any database technology.
At physical-level structural model describes units of data access controlled by a database management application. It is physical data storage structure, using the language of a specific database implementation technology. With a little more effort you can turn the structural model into a set of random access files and indexes.
For now, we can largely ignore the fact that the structural model (at the logical level) and the data storage structure (at the physical level) might have different structures. Much of the advice that applies to structuring one applies equally well to structuring the other.
Behavioral models
Some kinds of constraints and derivations, even some multiplicity constraints, are not readily documented in a structural model. But you can specify every constraint in the behavioral model (or “dynamic schema” as some call it), as a precondition of one or more events that hit the entities defined in the structural model.
You can model the behavior of an activity system from both entity and event-oriented perspectives. The entity-event matrix below helps to show how entity and event-oriented views are orthogonal views of the same system.
|
Persistent
entity Transient event |
Entity
Life History Views |
||
|
Pupil |
School |
||
|
Event
Impact Views |
Pupil
Registration |
Create
Pupil |
|
|
Pupil
Enrolment |
Tie
Pupil to School |
Gain
Pupil |
|
|
Pupil
Transfer |
Swap
Schools |
Lose
Pupil / Gain Pupil |
|
|
School
Closure |
Cut
Pupil from School |
Lose
All Pupils |
|
Notice that:
·
A column
contains the entity-oriented view of behavior, which is representable in entity
life history diagrams or state charts.
·
A row
contains the event-oriented view of behavior, which is representable in event
impact structures or interaction diagrams.
·
A cell
can be completed with entries like create, update and delete, or with more
specific event effects as shown above.
Event impact views
The table below illustrates how one event affect several entities.
|
The event effect
principle |
Analysts specify the
effect of a transient event on a persistent entity - not the operation(s)
that implement that event effect. |
This event impact view is a specification rather than an implementation; it says what is to be done rather than how it is done.
|
Event: Divorce |
||
|
Entities affected |
Preconditions |
Post conditions |
|
Marriage |
Marriage Status = active |
Marriage End Date = Divorce Date Marriage Status = historic |
|
Person [wife] |
|
Marital Status = unmarried |
|
Person [husband] |
|
Marital Status = unmarried |
A Divorce succeeds or fails as a whole. A Divorce event will trigger a number of operations on entities. If the event finds a necessary precondition is untrue, then it must fail, backing out any operation done so far.
The booklet “Event model patterns” discusses three ways to implement an event impact view. For object-oriented programming, you would extend the interaction with implementation-specific detail to do with message passing. For service-oriented procedural programming, you would base the programming on a read/write access path.
Entity life history views
State: Every entity experiences events and responds to them. An entity’s memory is often called its state. Transient entities see only one event at a time, and have no memory of past events. Persistent entities see a stream of events over time, and retain a memory of what has happened.
State machines: The stream of events affecting a persistent entity is describable as a state machine. A state machine exists, it happens, whether you document it or not.
Events in a state machine: The object-oriented principle of encapsulation means that nobody but an entity can see its own memory, its own state. So any event that inspects the state of an entity must (by definition) appear in its state machine.
Life history analysis investigates and documents the state machines of the co-operating entities that form an application. There are various ways to document a state machine. Some are limited to recording events and states. A simple state transition diagram specifies the states an entity can be in, the state transitions it can undergo, and the events that cause those state transitions.
A life history diagram or state transition diagram specifies constraints on the sequence of events in a state machine.
The isomorphism of behavioral model dimensions
You can document the same rule both views. We generally favour
documenting rules in event impact views. We usually use the entity life history
view only as an analysis tool. But the reverse approach is possible. Do what
works best.
(For all but trivial
systems, an entity-event matrix is not an adequate tool for documenting event
effects because one entity type can be affected by one event type in different
ways. Also, one event can have multiple effects on objects of one entity type,
and trigger multiple operations within one effect.)
The isomorphism
of structural and behavioral rules
When people talk about rules, they usually mea constraints on input data and/or derivation rules for output data. These validations and calculations can be divided another way into invariant and transient conditions.
· An invariant condition - guaranteed to hold true at any time - may be declared as a property of a persistent entity.
· A transient condition - guaranteed only immediately before or immediately after a discrete process - may be declared as a property (a precondition or post condition) of a transient event.
You can recast every rule in a structural model as one or more rules in the corresponding behavioral model. Whether you should do this is one of the questions every rule guru needs to have an answer for.
The only time that any rule can be applied is when an event is processed. So, structural rules can be thought of as being a subset of behavioral rules – the subset that are applied by every event (at least, every event thought of so far).
Structural and behavioral rules are complementary. Without the former, you would have to duplicate rules in lots of processes. Without the latter (as Jim Rumbaugh says) “you would have to invent lots of baroque structural rules” There is a trade off.
Do you want simplicity? Defining rules in the structural model makes programming easier. All software developers can trust the rule will be applied without thinking about it, or coding any reference to it in their programs.
Or flexibility? Defining rules in the behavioral model reduces the need to alter the structural model when requirements change. You can change a behavioral rule in one or more event processes without having to change the structural model.
Where the cost of changing the structural model is high, then you may choose to turn every structural rule into a behavioral rule, even though it means disobeying the SPOD principle and locating the rule in several places.
A way to limit the damage is to put the rule into an infrastructure module invoked from every relevant event. In other words, implement the behavioral rule so that it follows the SPOD principle and has the effect of an invariant rule.
Conclusions
This section has illustrated how rules might be documented from three different perspectives, using diagrams. Most of our papers focus on building a logical rules model that can be coded against a real database. You can also build a conceptual rules model acting on a theoretical database.
Subdividing Terms, Facts, Constraints and Derivations
Terms
Terms are the words used by application purchasers and users in their universe of discourse, to describe their business. A term describes how people think about things. Our scheme adds behavioral terms that people used to talk about events and actions rather than things.
Disagreements about the meaning of a term can be disastrous.
“Told to ‘Secure a building’ the Marines will form a landing party and assault it; the Army will occupy the building with a troop of infantry; the Air Force will take out a three year lease with option to purchase.” Attributed to James Schlesinger.
It is important that application developers and business people talk the same language. They have to beware of synonyms (different words with the same meaning), and homonyms (the same word with different meanings). Homonyms are usually the more dangerous. Both synonyms and homonyms can act as a serious drag on a development project, especially where there is more than one specifier. So, one should never, ever, introduce a new term without also describing the meaning of that term in a short text definition. This definition should just be enough to reduce the dangers of synonyms and homonyms, and resolve the conceivable misunderstandings.
Defining a term establishes the most elementary kind of rule. Terms in appear in two kinds of model.
Structural terms are the names of things that persist. They appear in software specifications as the names of entities, attributes and relationships in a structural model.
Behavioral terms are the names of things that are transient, that happen but do not persist. They appear in software specifications as the names of events, event parameters and operations in a behavioral model.
How useful are terms on their own? Not very. Terms must be defined, but you can’t do anything significant with terms on their own.
Facts
A fact, in the Business Rules Group’s scheme, describes the nature of a business in terms of the facts that relate terms to each other. Their focus is on structural terms. Our scheme adds behavioral facts; these relate behavioral terms and facts to structural terms and facts.
A structural fact relates structural terms to each other in some kind of structural statement. It connects persistent things to each other. E.g. People have Names, Husbands marry Wives, and Customers place Order s.
People normally specify structural facts as attributes and relationships of classes. Strictly, the multiplicity of a relationship is not part of the fact; it is a constraint upon that fact. E.g. It says in English law that ‘marriage is the union of one man with one woman’.
The multiplicity in the example (one with one) is a constraint on the fact, rather than a fact in itself. So, a structural fact says less than a relationship line drawn in a structural model. Think of structural facts as attributes and relationships without multiplicity information.
How useful are structural facts on their own? Perhaps they are useful in a conceptual model. But they are not very useful in a logical model. You normally specify constraints (at least multiplicity constraints) on the facts at the same time, or very soon after.
Behavioral facts are of two kinds. The first kind is an event parameter, a fact about an event, often a new value for a fact that is stored about a persistent entity. The second is a behavioral statement that relates behavioral terms to structural terms; the statement says what persistent things are affected when something happens. E.g. Wedding events marry Grooms to Brides.
In practice, the multiplicity of the entities affected by an event is virtually inextricable from the behavioral fact itself. E.g. A Wedding event marries one Bride and one Groom.
You can define the multiplicity constraints, then abstract the behavioral fact by removing any statement of multiplicity.
People normally specify behavioral facts using a view of a structural model – an interaction diagram that shows the collaboration between entities when an event occurs. An interaction diagram tells us which entities are affected by an event, which Order they are discovered in, and how one entity governs the access to other entities. How useful are these behavioral facts on their own? The Booklet “Event model patterns” suggests they are rather more interesting than structural facts.
Constraints
A constraint limits the values of an attribute or the multiplicity of a relationship, in a structural model,. Our scheme adds further constraints to behavioral models where analysts specify the preconditions that constrain events, that is, prevent events being processed.
Not every condition is a constraint. Two kinds of
condition may be distinguished:
·
a fact
condition – chooses one path in
a process rather than another, selects between optional effects
·
a
constraint condition – prevents
a process and/or rolls back a process and raises alarm.
UML includes the concept of “guard” conditions,
which can be annotated on transitions in state charts. But this is a code
modelling concept rather than a rule modelling concept. A guard condition could
be either a fact condition or a constraint condition.
A rules engine works on the basis that a rule
takes the form: “If condition do action”. But that is no basis for a rules
specification paradigm, since every application can be entirely expressed as rules of this kind.
Analysts can specify the business constraints on
business events as preconditions of business services. After much deliberation,
we concluded that preconditions must embrace two kinds of condition:
·
do not start
process unless condition is true
·
start
process but fail unless condition is true.
In academic circles, preconditions mean only the
former. But this is not an adequate or workable basis for rule specification.
Consider a real-world church wedding service. It will start, but then be rolled
back if any of the assembled entities reply to the control entity’s request for
a “just cause or impediment”.
Preconditions do work like that in the real
world. They often have to work like that in applications that model the real
world.
There are many circumstances where it is good
practice to invoke a software process on the basis that it will “start but fail
unless condition is true”. This is true of any multi-user application, any
multi-client application, and any application where you cannot trust the
supplier of the input data.
So, our method is explicitly based on the
assumption that the platform includes a roll-back service (whether this
platform is provided or we have to build it). The roll back service will ensure
each business service is a “discrete event”, moves the component from one
coherent state to the next, never finishes leaving the component’s data store
in an incoherent state.
A structural constraint is an invariant, that is a precondition that applies to every possible event. It remains true forever (or at least until the rules of the application are changed). People normally specify a structural constraint as a property of an entity, attribute or relationship in a data model.
E.g. they may specify for:
· a relationship – a multiplicity rule that restricts the number of entities involved
· an attribute – a domain or data type that restricts the range of values
A behavioral constraint is a precondition that applies to one or more event types but not all, that remains true only until it is contradicted by the passage of time (or more exactly, by the arrival of other events).
People normally specify a behavioral constraint as a property of an event or operation in the behavioral model. E.g.
|
Event: Wedding |
|
|
Entities affected |
Preconditions |
|
Person [bride] |
Age > 18. Status = unmarried. |
|
Person [groom] |
Age > 18. Status = unmarried. |
The preconditions
for a Wedding are clearly only relevant at the moment of the Wedding event.
Immediately after the Wedding, the people will be married, and so ineligible
for another Wedding.
So, what is wrong with this entity-attribute view?
|
Entity: Order |
|
|
Attributes |
Invariants |
|
Order Number |
|
|
Order Value |
Order Value <
Customer Credit Limit |
The entity table
suggests that the constraint is an invariant, applied to current attribute values.
But it is not an invariant rule, it applies only at the moment that somebody
attempts to place an Order . Tomorrow, somebody may reduce the customer’s
credit limit, meaning that an Order accepted today would appear invalid.
Provided that its preconditions are satisfied, then the process of event is bound to satisfy its post conditions by executing all its derivation rules.
Note that behavioral constraints not only add to, but also embrace, structural ones. You prevent invalid attribute values from being recorded, and relationships from being improperly tied or cut, by declaring preconditions that prevent events from being processed. When a precondition is not true, the event should fail.
Derivations
Derivations, in the Business Rules Group’s scheme, define how knowledge in one form may be transformed by calculation into other knowledge, possibly in a different form.
In our scheme, there are two kinds of derivation, structural and behavioral. We have to extend the Business Rule Group’s definition somewhat so that derivations cover all manner of processes that lead to a post condition of an event.
A structural model derivation specifies the value of data as invariant state of affairs, true before and after every event. People normally specify a structural derivation as a property of an entity-attribute-relationship view. E.g.
|
Entity: Person |
|
|
Attribute |
Invariant |
|
Age |
= Todays Date –
Date Of Birth |
A behavioral model derivation is a post condition that specifies the value of data just after an transient event has been processed. It holds true only immediately after that event. People normally specify a behavioral derivation as a property of an event or operation in the behavioral model.
Every attribute update can be defined as a behavioral derivation. The most trivial update rules declare how a value in the database is derived from a value input as a parameter of an event. E.g.
|
Event: Address change |
|
|
Entities affected |
Post conditions |
|
Customer |
Address [new] = Address [input event] |
|
Event: Withdrawal |
|
|
Entities affected |
Post conditions |
|
Customer |
Balance [new] = Balance [old] – Withdrawal
Amount [input] |
You might specify
derivations as post conditions using a formal declarative language such as OCL,
but this can be very tedious. People commonly write some kind of pseudo-code
that shows the effect of an event on stored data.
For a more interesting example, odellin how Order ItemValue is calculated when Order is placed (but not every time the ProductUnitPrice is subsequently changed).
|
Event:
Order placement |
|
|
Entities affected |
Post conditions |
|
Order |
Order Value = Gross Order Value – Discount |
|
Order Item |
Order Item
Value = Amount * Product Unit Price |
Note that we have
focused on the stored data, but further derivations may be specified.
Derivation expressions may be attached to transient working storage data items
used during a process. E.g.
|
Event:
Order placement |
|
|
Event state |
Gross
Order Value = sum of Order Item Values placed so far during the event
processing |
|
Entities affected |
Post conditions |
|
Order |
Order Value = Gross Order Value – Discount |
|
Order Item |
Order Item
Value = Amount * Product Unit Price |
Derivation
expressions may be attached to output data items in entity-attribute view. E.g.
|
Entity: Customer
display screen |
|
|
Attribute |
Invariant |
|
Age |
= Date
Today – Date Of Birth |
Derivation
expressions may be embedded inside behavioral constraints or preconditions.
Notes on rules and models
Before setting out a method for rules analysis and specification, we ought to confront several ambiguities and challenges, consider some principles and offer a format for documenting rules.
Which model view does a rule belong in?
People who use one kind model to document rule don’t always appreciate that the same rule may be better documented in another kind of model.
Some believe entities are more fundamental than events, so they suggest analysts define and extend a structural model to capture every rule.
“Business rules represent terms, facts and rules – the basic knowledge
part of an overall problem. Business rules are not any of the following:
inputs, processes, outputs, sites or connections, actors or work products,
events or timeframes.” Ron Ross
What Ron say is true where he is coming from. It
is the view taken by many enterprise data architects. And it is possible
to take this view because (with some effort) every event can be odellin as an
entity if you choose to this.
But Ron surely knows those who advocate OO design
or formal specification take a different view. In those worlds, rules include
preconditions and post conditions as well as invariants. Processes are defined
in a declarative form by preconditions (related to what Ron knows as
constraints) and post conditions (related to derivations).
Also, Ron’s use of the word ‘knowledge’ is restrictive.
Business people really do know and care about business events as much as they
care about business entities, and so should systems analysts!
E.g. A registrar is concerned not only with marriages (which are entities in our structural model) but also with weddings and divorces (which are events in our structural model). All of these are clearly terms of interest in the registrar’s universe of discourse.
Some rules sit well in a structural model. Some
rules sit better in a behavioral model (think of state charts and interaction
diagrams). You have to decide in which dimension to specify a specific rule.
The
effect of physical boundaries
People who promote a logical model they have
built don’t always appreciate the extent to which the structure of their apparently
‘logical’ model already depends on decisions made about the physical boundaries
of components and transactions.
|
The distribution
challenge |
Analysts cannot
reasonably assume that all applications will run on top of a single enterprise
database – they must account for distribution of data storage. |
A transaction is a process that can be rolled
back if a rule is contravened.
|
The transaction
principle |
Analysts initially
posit that an automated business service, triggered by a business event, can
be rolled back automatically. This rule of thumb make specifications simpler
and more consistent. |
It is not much use defining invariant rules in a
logical entity model if the entity data is so far physically distributed that
no platform can roll-back a mistaken business service. The effect of
distributing data about related entities is to turn business services (that
preserve invariant rules) into workflows (that accept the rules will be
broken).
So, dividing a system into business components, and/or building a system from pre-defined distributed components, can have a big impact on analysis and specification.
|
The data integrity
concern |
Analysts strive to
maintain data integrity by defining rules that constrain all the users and
clients that can update entity state data (which means, by the way, that they
posit defensive design rather than design by contract). |
|
The cache concern |
Analysts regard
caching business data outside the enterprise’s persistent data stores as a
design optimisation technique and a design headache, not a primary design
principle. |
|
The data
duplication concern |
Analysts have to
define workflows to synchronise copies or entity state that are duplicated
beyond the bounds of automated transaction management. |
Ambiguities in the classification of rules
Here is an example rule, specified declaratively.
·
Order Value
= Order Amount * ProductPrice.
Many questions can be asked about this rule.
Is this rule invariant or transient?
It could be either. It is an invariant rule if
you retain the ProductPrice used in the calculation for as long as the Order
Value and Order Amount. It is a transient rule if you allow the ProductPrice to
be overwritten and do not retain past prices in memory.
If you are not ready to propose whether or not
old prices should persist in a data store, then you are not ready to build a
logical model of a system. You might however declare the rule in a precursor to
this – in workshop notes, a data dictionary, an Object Role Model, or whatever.
Is the
attribute stored or derived when needed?
If the rule is an
invariant, the systems analyst can leave that decision to the database
designer. Otherwise the attribute will almost certainly be stored.
Is this rule declarative or procedural?
It is expressed in a declarative form, but it
would be a trivial matter to express the rule in a procedural form. You need
only agree a simple action language, such as:
·
Set Order
Value = Order Amount * Product Price
·
Order Value := Order Amount * Product Price
Some propose that declarative specification is
better than procedural specification. That is not always true.
Is this rule a “constraint” or “derivation”?
It could be both. The term “constraint” usually
means a precondition that must be true before a service can happen. The term
“derivation” usually defines post condition that results from the processing of
a service, such as the calculation of an attribute value using persistent data.
So, you may speak of there being a derivation
rule for Order Value. But provided the rule is an invariant, then it might also
be called a constraint on Order Value.
Fixed and modifiable rules
A fixed
rule can be changed only by changing the model; this implies a developer
must alter code.
A modifiable
rule can be changed without changing the model, implying an external user
alters a data value by using a service of the system.
“Some dynamic rules may be enforced using a populated static fact type,
e.g., adding role names in square brackets,
Marital Status [From State] may
change to Marital Status [To State],
We can store a table of From/To state pairs (Single/Married,
Married/Divorced, and so on). Then set a rule that reads this table to ensure
only transitions from the From State to the To State are allowed.
Demoting metadata to data in this way allows some rules to be modified
simply by changing the data without recompiling the schema. This is of course a
well-known technique that has been used for decades.”
Terry Halpin.
Decisions about what rules users can modify are
important; they shape how analysts build a model. These decisions are made in
the light of non-functional requirements as well as functional ones.
Thoughts on models
It is easy to lose your way when building models. There are several points to remember about a rules model that can help keep you on the right track
· Notations are not the main issue. You can use any diagram notations that captures the necessary semantics. You can use standard notations like those of UML. There is no reason why you should not convert every table in this booklet into the notation you are most familiar with. We have deliberately avoided using a graphical representation, so far, since notations are not the main issue here.
·
The three
dimensions always exist. Some
people choose to specify only one dimension of the rules model. A database
designer might specify only the structural model. A process control application
designer might specify only the entity interactions. A coding language may lead
you to concentrate one dimension rather than another. However, all three
dimensions exist, whether you choose to specify them or not. And you can
reverse-engineer all three dimensions out of an existing application, though
perhaps not as easily as some tool vendors would have you think.
· The three dimensions are inter-dependent. The three dimensions are perspectives of one specification, three views of one underlying rules model, to be kept in step. Some CASE tools have automated transformations between structural and behavioral models. So you can, for example, derive events models semi-mechanically from a full set of life history diagrams.
· The model should be consistent. The model should be consistent with the rules of the business. A meaningful and useful structural model, life history diagram or interaction diagram reflects the requirements of users. Then, the parts of the model should be consistent with each other. If they are not, then anybody who tries to use the model will lose faith in it and may come to disregard it.
· No dimension has precedence. People may pretend in a presentation or paper that they specify the three dimensions in sequence, one after the other. Do not even think of trying to doing this. Experts develop the dimensions in parallel, nudge one dimension forwards and immediately cross-check it against the other dimensions. This process of cross-checking helps to refine the design.
· Modeling is reuse. Modeling and reuse are two faces of the same coin. A goal of modelling is single point of definition or declaration (SPOD), meaning that a rule is specified and coded only once – and shared by all clients who need that rule to be applied.
· The best kind of rules model is codable. We want a rules modelling process that runs from requirements capture to program coding. One may draw rule diagrams merely as pictures to prompt discussion. One may limit diagrams by artificial guidelines such as ‘fit on a page’ or ‘less than 20 boxes’. But the best kind of rules model is usable as a software specification by designers and software developers. Many CASE tools can generate a database schema from a structural model diagram. Some application generators can build a crude data recording application from this alone. To produce proper applications, the model must include the behavioral constraints and derivations. Some CASE tools are able generate working code from behavioral model diagrams.
· The model is limited. You can build a model that is logical in the sense of being technology-independent, but it is not directly a model of real-world entities. It specifies only data entities. These represent only very limited aspects of the real-world entities in the application’s environment.
The model must be validated
There lots of models out there – documented during the specification of software systems. Most of them are structural models. Some are behavioral models. The fact is that many of the models out there
· are poor representations of the ules – they miss important constraints, or they miss important relationships altogether, leading to extra costs, for users who don’t get the application they want, and for software developers who have to program around the missing rules.
· duplicate each other – leading to extra costs for users and software developers, especially in maintenance and regression testing.
· conflict with each other – leading to extra costs for users who have to reconcile the mismatches in stored data, and software developers who have to write programs to detect and report on the mismatches.
· are not used as they were supposed to be – many conceptual models are disliked by those are supposed to use them, and many such models are disregarded in practice; many logical models are treated like conceptual models.
There is a tremendous need for models to be validated, ideally before they are implemented. Applications analysts need tools to help them validate the model against the rules of the business.
Later booklets outline systematic ways to discover, think about and analyse rules. The next booklet features a list of analysis questions. Later booklets catalogue patterns and schema transformations. Also, Mike Burrows has developed a CASE tool – Validator – to assist in structural schema transformations (<www.asplake.demon.co.uk>).
Applications analysts need to validate that the parts if the model are consistent with each other. Better, you want to use a CASE tool that prevents, or at least strongly discourages you, from building an inconsistent model in the first place. The way to ensure consistency of a Three-dimensional entity-event model is to make sure the three dimensions are glued together via a set of common underlying attributes and operations.
Concluding remarks
Analysts are expected to
gather some rules in requirements,
and go on to specify these rules more precisely structural and behavioral
models of data processing.
|
The business rule
principle |
Analysts declare
business rules as invariants of entity state, as preconditions and post
conditions of event effects; and define volatile rules as user-updatable
attribute values. |
This and the following booklets:
·
adopt conventions of discrete event modeling,
·
extend those with the formal specification concepts of
pre and post conditions.
·
define rules along with entities and events.
·
balance invariant and transient rules, static and
dynamic rules.
·
recognise ambiguities in the classification of rules.
·
extend the Business Rules Group scheme by loosely
subdividing each kind of rule. into structural and behavioral varieties.
·
put rules in the context of business process control
flow.
·
focuses on update rather than enquiry services.
·
address both fixed and modifiable rules.
·
encourage SPOD.
References
Ref. 1: “Abstraction in all its variety” in the Library at http://avancier.co.uk
Ref. 2: "Business Rules and Information Systems" (Addison-Wesley, 2002) Tony Morgan
Footnote 1: Creative Commons
Attribution-No Derivative Works Licence 2.0
No Derivative Works: You may
copy, distribute, display only complete and verbatim copies of this page, not
derivative works based upon it.
Attribution: You may copy,
distribute and display this copyrighted work only if you clearly credit
“Avancier Limited: http://avancier.co.uk”
before the start and include this footnote at the end.
For more information about the
licence, see http://creativecommons.org