There are several books currently in publication that describe the importance of term-fact modeling when developing business rule systems.  These include Tony Morgan's book, Business Rules and Information Systems, Ronald Ross' book, Principles of the Business Rule Approach, and Barbara von Halle's book, Business Rules Applied.  One of the key points made by all of the authors mentioned is that business knowledge is at the center of business rule systems. 

Business knowledge is expressed using words and phrases that make sense to the business people.^[1]   Facts build on the terms and express the things that business people know about their business.  Rules use facts to help control business operations to make sure that business is being performed the way the business people want business to be performed.  Terms form the foundation upon which business facts are built.  Business rules are built on top of business facts.  Business rules use business facts and interact with one another to guide business operations.

The work that results in successful business rule discovery, analysis, modeling, and implementation all starts with term and fact identification and term-fact modeling.  This article focuses on the analysis and modeling techniques that I have used over the years^[2] in order to complete successful term-fact modeling and lead to efficient, successful business rule applications.

As Ron Ross points out, business terms are words and phrases that have meaning to business people in the context where those terms are used.  Facts are combinations of business terms that describe what business people know about their business.  So where do terms and facts come from?  How are terms and facts identified?  How do we model terms and facts in order to effectively use them in business rule applications?  What are the deliverables from term fact modeling?  This article will provide some answers to these questions.

Before going further, I want to say a quick word about ambiguity.  Use Cases and the scenarios based on those Use Cases are usually expressed using natural language and consequently they can be ambiguous.  Humans have the natural ability to interpret Use Case descriptions and scenarios and to 'fill in the gaps' caused by ambiguity.  Computers, on the other hand, deal in precision.  Computers cannot 'fill in the gaps' the way humans can.  Term-fact modeling provides the means to eliminate ambiguity from Use Case descriptions, scenarios, and business rules so the computer needn't 'fill in the gaps'.  Figure 2 represents a view of the role that term-fact modeling plays in introducing precision into the business rule discovery and analysis process.^[3]

Answering the Questions

Where do terms and facts come from?

Use Case analysis is one of the primary ways that terms and facts are identified.  Use Cases contain a narrative describing the situations under which a particular aspect of an automated system is used.  The narrative is packed with business terms and facts.  In addition, the narrative often identifies decision points -- places in the Use Case where at least one business rule must be enforced.  A Use Case is usually accompanied by a diagram that identifies the human or non-human actors, with the names of the Use Case and any extended or included Use Cases   Use Cases are supported by scenarios.  These scenarios are useful for fact identification as they capture the business users' knowledge about business processes and decisions, and the situations that can cause decisions to change. 

Terms and facts can be extracted from documentation such as business policies, standard operating procedures, governmental regulations, contracts, and other printed materials.  Terms and facts can also be extracted from a business' current software applications and database definitions.  This approach is the least favorable because it usually results in the acquisition of terms and facts as seen by the IT technicians who implemented the software solutions and may not represent the actual vocabulary and knowledge of the business people and business processes. 

How are terms and facts identified?

Terms can represent different things in the business context.  The things that a term can represent include:

• Abstract Business Concepts -- Business Object Class
• Concrete Business Things -- Business Object Class
• Characteristics -- Attribute/Data Member
• Behaviors -- Method

Facts describe what business people know about their business.  Facts can describe what business people know about the business objects used in their business.  Facts provide clarity to understanding abstract business concepts and describe concrete business things; they describe constraints associated with characteristics, such as size limits, thresholds, etc.  Facts often describe the relationships between business concepts and things. 

A Use Case narrative is typically full of facts and terms.  A narrative identifies the actors who gain some form of benefit from the Use Case.  The Actors may be humans or automated systems.  The narrative will typically begin with a business event, e.g., "A prospective customer requests an insurance quote."  The narrative then usually describes a series of activities that are to be performed by an automated system in order to generate the required benefit from that system.  The activities will all contain business terms and facts. 

Use Case Analysis is the software design activity that enables term and fact identification.  During Use Case Analysis, it is often helpful to ask some simple questions to get a better explanation of the meaning of a term in the business context -- questions like:

• "What is <term>?"
• "What does <term> look like?"
• "Is <term> similar to other < term>?"

The answers to these questions are facts.  They describe what business people know about their business and they will allow you to decide if <term> is best represented as a business object class, as a characteristic of a business object class, as a behavior of a business object class, or as relationships between business object classes.

How do we model terms and facts in order to effectively use them in business rule applications?

Two standards that are maintained by the Object Management Group (OMG) provide extremely useful guidance for the performance of term-fact modeling:  the Model Driven Architecture (MDA) and the Meta Object Facility (MOF).

The MDA emphasizes the creation of computation independent models (CIM), platform independent models (PIM), and platform specific models (PSM) in order to guide application development.  Business terms and facts are stated in natural language and are by definition totally independent of any computing platform.  CIM and PIM are platform independent models of the business domain and are therefore the most important models supporting business term-fact modeling.

The MOF provides the conceptual guidance necessary to actually construct meaningful term-fact models.  The MOF is platform independent and therefore encourages the development of PIM.  For example, the MOF allows the use of inheritance to create hierarchies of classes.  The MOF allows multiple inheritance to facilitate a clearer understanding of the business domain semantics.  The MOF describes three relationships that are essential in term-fact modeling:  Generalization, Association, and Aggregation.

Generalization is the relationship that facilitates creation of class hierarchies.  The colloquial term for generalization is 'is-a'.  Generalization encourages the abstraction of common characteristics and behaviors to the highest logical levels of a class hierarchy.  Generalization enables the modeler to describe abstract business concepts and concrete business things.  Any time the question "what is <term>?" can be answered with the response "<term> is other < term>" the answer may indicate that the generalization relationship should be explored.  At a minimum, the answer indicates that two terms are synonymous and indicates that some common term must be established to avoid ambiguity among the business users and to eliminate ambiguity in computer applications.

Association is used to describe relationships between pairs of classes.  Associations can be navigable in one direction, from one class to another, or bi-directional.  Association is often colloquially called 'uses'.  Association indicates what one class 'knows' about another class.  The concept that classes 'know' about other classes is fundamental to modeling facts.  Navigability also indicates that one class may delegate work to another class.  Association can be used to indicate that one class may delegate work to another class.

Aggregation is used to describe the situation where one class has components that are other classes.  The colloquial terms for aggregation are 'has-a' and 'part-of'.  Like association, aggregation is navigable in one direction or bi-directionally.  Navigability of an aggregation relationship indicates that one class may know that another class is a part of itself or a class may know that it is a part of another class.  The decision of the need to provide navigability in an aggregation relationship is guided by 'what makes sense'.  For example, it may make sense that an automobile 'knows' that a particular engine is a component but it may not make sense that an engine 'knows' that it is a component of a particular automobile -- the reason, engines are removed from and replaced in automobiles all the time.  The automobile can delegate work to the engine however the engine can not delegate work to the automobile.

The MOF describes a feature called cardinality.  Cardinality can be used to express the number of class instances (objects) that participate in an association or aggregation relationship with other class instances.  When used in conjunction with association and aggregation, cardinality provides an added dimension for expressing constraints. 

The Unified Modeling Language (UML) provides excellent tools to perform term-fact modeling.  The UML is based on the MOF; therefore it provides generalization, association, and aggregation as well as allowing specification of cardinalities.  The UML also offers the Object Constraint Language (OCL), which can be used to enrich model semantics. 

What are the deliverables from term-fact modeling? 

Term-fact modeling is performed to capture the business semantics in a way that enables development of rule-based systems.  The first deliverable of the term-fact modeling process is a collection of platform independent models that can be converted into platform specific models for the application that is being developed.  Platform independent models are crucial because they represent the business in its simplest form. 

The first and most important deliverable of term-fact modeling is the definition of the terms that are important in the business domain.  In most cases term definitions are provided in a business glossary.  A complete business glossary is not necessary in order to move to the next deliverable, however.  The business glossary template in Table 1 is useful for defining business terms and provides a mechanism to describe the term's business use, for example, a term might represent an abstract concept, a concrete thing, an attribute, or a behavior.  The description often contains facts that are important to completing the term-fact modeling.  The description can also be looked upon as a statement of a business requirement.  The description can lead to other facts that are not explicitly stated but that must be captured in order to properly represent the business environment.  For example, the description of the various Customer terms in Table 1 was extracted from The Enterprise Ontology.^[4]

Table 1. Business Glossary Template

Term	Description	Business Use
Actual Customer	The role of a Legal Entity agreeing to exchange the Sale Price for a Product in a Sale.	Concept, Role
Potential Customer	Any Legal Entity who may become an Actual Customer.	Concept
Customer	Any Legal Entity that may be an Actual Customer or a Potential Customer.	Concept

The various Customer descriptions in Table 1 provide additional business terms that must be added to the glossary.  The description of an Actual Customer contains additional facts that must be extracted, captured, and modeled.  For example, the fact 'A Product is offered for Sale at a Sale Price' indicates that every Product has a Sale Price.  One must dig a bit deeper into the Enterprise Ontology to find that a Product is a generalization used to describe a Good, a Service, or a Currency.

Following the development of the Glossary of Business Terms, a semantic network can be developed.  In the semantic network, terms are represented by nodes and the relationships between the terms are represented by labeled arcs.  The labels on the arcs represent relationships between the terms.  Semantic networks can become quite complex and involved.  Figure 3 is the semantic network that describes the fact 'A Legal Entity may perform a Customer Role ' and Figure 4 represents an example of a simple semantic network that generalizes the Customer description from Table 1 and represents the fact 'Any Legal Entity may purchase any Product'.

Further research into the Enterprise Ontology leads to the identification of the Entity concept.  An Entity is something that may perform Roles in the business domain.  Entity, Legal Entity, Role, and Product can be represented as a Class in the Object-Oriented Analysis and Design paradigm.  These classes can be diagramed using the Unified Modeling Language as demonstrated in Figure 5, a platform independent UML class diagram.  This class diagram represents a conceptual view of the relationships between Entity, Legal Entity, Role, Customer Role, and Product   The platform independent model is the third deliverable of the term-fact modeling process.

The third term-fact modeling deliverable is the logical model that is developed by expanding the conceptual model.  The logical model is often developed in conjunction with a data modeler or a data base administrator.  The logical model can be represented with a fully-attributed UML class model or it may be represented with an Entity Relation diagram.

By taking advantage of tools such as the Eclipse Modeling Framework (EMF), the logical model can be used to generate Java source code.  The Java source code generated forms the nucleus for the Business Object Model (BOM) source code that is essential to development of effective business rule systems.

Drive the Ambiguity out of Business Rule Systems

Ambiguity is the nemesis of all computer applications but is especially bad for business rule applications.  Ambiguity is rampant in all business domains.  Ambiguity exists because business policies, regulations, laws, and other documents are written in natural language.  People can manage the ambiguity and thrive in an environment where ambiguity rules.  Computer systems, especially rule-based systems falter and crash in such an environment.

Term-fact modeling is the most effective tool for driving ambiguity out of business rule applications.  When used in conjunction with the Model Driven Architecture, the Meta Object Facility, and tools such as the Eclipse Modeling Framework, term-fact modeling extends the analysts' capabilities, enabling the analyst to specify/discover business rules, discover the business concepts, characteristics, behaviors, and interactions, model these discoveries, and finally generate source code that forms the foundation for business rule systems.

References

[1]  Principles of the Business Rule Approach, Ronald G. Ross, Addison-Wesley, 2003.  

[2]  This article describes, in general, the approach to term-fact modeling that ILOG applies in its analysis and modeling techniques.  ILOG has developed the ILOG Solution Implementation Standard (ISIS) methodology in order to provide our clients a repeatable process that they can use to develop business rule applications.  ISIS is an extension of the Rational Unified Process (RUP) and as such, it places great emphasis on the performance of Use Case analysis, iterative, phased development, and visual modeling.  ISIS and the RUP also emphasize Use Case based scenario definition to support software system design, development, and testing.  Use Cases and Scenarios are the first and one of the best sources for gathering terms and facts.  Other sources for terms and facts include written documentation, such as business policies, standard operating procedures, contracts, etc., as well as business experts, and currently operating software systems and data models/databases.  

[3]  based on ILOG's approach  

[4]  The Enterprise Ontology, Mike Uschold, Martin King, Stuart Moralee and Yannis Zorgios, AIAI, The University of Edinburgh, 1997.  

# # #