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

Other rule classifications

Housing business rules in an entity-event model

More about Terms, Facts, Constraints and Derivations

Notes on rules and models



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.


“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.


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.

  • Waste should be minimised.
  • Data security is paramount.


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.

  • USB ports are disabled.
  • Message data at security level 3 is encrypted.

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.

  • AccessLevel = Low if UserType = Public.

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.


A catalogue of concept-level business rules


“A group must not include any union members if it includes any non-union members, and vice versa.”


“A poor-risk customer must not place a rush Order ”


“An employee’s new salary must be greater than or equal to the employee’s current salary.”


“A truck carrying hazardous material must not be routed through a downtown street.”


“A trainee must not send a memo to a manager without permission of his supervisor.”


“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.




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.


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.


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.


Defensive design


An automated service must test all its preconditions before updating stored data according to other defined business rules.


Prevent the corruption of data by clients who do not know the preconditions.


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.


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.


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.


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.


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.


Circle Mathematics Component

Entity State

Pi = 3.14



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.”


each Person has

at most one Age,

at most one MaritalStatus.

Allowed changes in MaritalStatus are:

‘Single’ to ‘Married’;

‘Married’ to ‘Widowed’,


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






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 UK since 1979) is to specify a rule in one of three views of an entity-event model.

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.


A structural thing that persists.  A thing that is created, affected and ultimately destroyed by events.


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 expressed in terms of the states it passes through from creation to deletion, and data events that cause state transitions.

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


Computation-Independent Model

Logical model


Platform-Independent Model

Physical model


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.



Structural model

Behavioral Models




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



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


Post conditions


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.


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 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.


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.


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


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




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, 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




= 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


Address [new] = Address [input event]


Event: Withdrawal

Entities affected

Post conditions


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 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 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




= 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 (<>).

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.





Ref. 1: “Abstraction in all its variety” in the Library at

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:” before the start and include this footnote at the end.

For more information about the licence, see