1. Introduction

The acceptance of SBVR (Semantics of Business Vocabulary and Business Rules)^[9] will be a breakthrough in productivity in requirements and structured knowledge management.^[5] [8]  SBVR is fundamentally a fact-oriented approach, which makes it comprehensible to many people.  It so happens that experience with this approach started in Europe in the seventies, and a mature business practice has been developed during the last 35 years.  The current version of this practice is called NIAM2007.^[7]

In this column we will primarily concentrate on describing the coherence of the essential concepts of SBVR, using part of the NIAM2007 methodology, and thus providing the reader with an easy-to-grasp framework for SBVR.  NIAM2007 uses fact type diagrams that combine the advantages of diagrams and precise natural language statements, by integrating diagrammatic and natural language aspects.  A small part of the EU-Rent example of Annex E of SBVR will be used to illustrate the process of specifying the most important business rule.

Figure 1.  Knowledge triangle

The knowledge triangle of Figure 1 represents the core concepts described in sub clause 10.1.1.2 of SBVR^[9] and a few other concepts, specific for NIAM2007, in diagrammatical coherence.

The knowledge triangle is divided into three vertical lanes.  The middle lane represents diagrammatical representations of structured knowledge.  The left lane represents verbalizations for business people, which represent the same knowledge in a way familiar to business people, i.e., a formal subset of natural language.^[3] [10]  The right lane represents the NIAM2007 'verbalizations to prepare for generalisation', which represents the same knowledge as perceived from the perspective to derive the next level of grammar.  The latter form of verbalization allows for generalisation, which is a step in the procedure of deriving the next level of grammar and will be described in a future column.

The knowledge triangle is divided into three levels of knowledge or facts:

1. Facts:  facts without a grammatical function, called ground facts in sub clause 10.1.1.2 of SBVR, e.g., 'The operating country Germany uses the business currency Euro', 'The operating country France uses the business currency Euro', and 'The operating country USA uses the business currency USD'.
   
   
2. Semantic Grammars:  facts with a domain-specific grammar function, called the domain-specific component of the conceptual schema in 10.1.1.2, e.g., 'For each country that is recorded, its currency must also be recorded' and 'Each country name recorded in this fact type has to be unique (i.e., the only occurrence of that name).'
   
   
3. Metasemantic Grammar:  facts with a generic or meta grammar function, called the generic component of the conceptual schema in 10.1.1.2, e.g., 'Each fact type must have a role or a sequence of roles for which uniqueness is required'.

It will be shown that level II contains the rules and concept definitions for ground facts and, in a future column, that level III contains meta-rules, i.e., rules for rules, including the meta-rules themselves as well as the relevant concept definitions.  Thus, level III describes itself.  Therefore, these three levels suffice for describing structured knowledge.

The triangle was chosen as the form to represent structured knowledge to show that there are always more ground facts than rules for them and more level II (domain-specific) rules than meta-rules.  This is the intent of defining rules:  rules about structured knowledge are made to make working with structured knowledge more productive.

In the knowledge triangle, the domain-specific component, as well as the generic component, of the conceptual schema is divided into seven related knowledge classes:

• Concept definitions (CD)
• Fact types (FT)
• Fact type readings (also known as sentential forms) (FR)
• Constraints (CS)
• Derivation rules (DR)
• Exchange rules (ER)
• Events (EV)

These knowledge classes are part of SBVR as well as NIAM2007, except for exchange rules and events, which are not part of SBVR.  Why are they in the knowledge triangle?  To facilitate respectful discussions with other communities, such as UML.

SBVR is a major step forward towards widespread application of semantics in business and education.  SBVR is the first specification in business computing where concept definitions are first class citizens.  The concept definitions form the bridge between the formal and the informal world, hence are vital for business communication.  Concept Definitions (one of the seven knowledge classes at both the domain-specific level and the generic level) form the basis for each of the conceptual schemas — the domain-specific component and the generic component.

2.  Use Case EU-Rent 1.2

A substantially-reduced version of the EU-Rent Use case presented in Annex E of SBVR is given below:

EU-Rent Use case 1.2

1. EU-Rent rents cars to its customers.
2. It is obligatory that the rental charge of a rental is:
   1. calculated in the business currency of the country.
   2. This is a currency in which EU-Rent undertakes financial transactions in that country.
3. The used business currencies are Euro (EUR), GBP (British Pound) and USD (United States Dollar).
4. Every country only uses one business currency.
5. In each country in which it does business EU-Rent has an Operating Company.
6. EU-Rent's current operating countries are USA, France, UK, Germany, and Italy

Regarding this use case, in this column we first wish to focus on the domain-specific component of the conceptual schema.  First of all, a sample graphical report has to be made regarding the different operating countries of EU-Rent and their respective currencies.

Figure 2.  Graphical representation of operating countries and their business currency

Figure 2 is a graphical representation of facts illustrating the use case described above.  It is a sample report and could be called a data use case.^[4]  Since the diagram represents actual facts satisfying the data use case, it is possible to verbalize the contents as if the business professional is talking to a colleague over the phone and writes down the textual representation of the represented facts.  This is what is called "to verbalize a graphical representation."  Extensive experience with fact orientation during four decades has shown that starting with a concrete example of a data use case represented in the preferred notation of the business user is the most productive way to start requirements engineering and illustrate business processes.  It is also recommended for knowledge elicitation.

If we ask a subject matter expert or business person to verbalize the given information of Figure 2, the following sentences or facts will result:

Table 1. The result of verbalization by the domain expert

As a first step towards a structured specification or conceptual schema, for every fact or sentence it is indicated where the variable and where the constant sentence elements are located.  The result of this operation is presented in Table 2.

Table 2.  The result of assigning constant and variable parts

As can be seen from Table 2, there are two constant elements in each sentence, i.e., elements that are the same in each sentence (in this case "Operating country" and "uses the business currency", respectively).  There are two variable elements in each sentence, i.e., elements that have potentially different counterparts in the other sentences.  The first variable element of each sentence is an example of an operating country and the second variable element of each sentence is an example of a business currency.

Like professionals in many other professions, extensive use is made of pattern recognition in the NIAM2007 methodology.  From which fact type reading are the five listed facts an instance, an instantiation, or a realization?  We can conclude that we are dealing with sentences or facts that can be generated from the same fact type reading by filling in a value in two places, while the other elements consist of the same information for every sentence.  The places in the fact type reading where the variable elements are to be filled in to form sentences are called the 'placeholders' of the fact type reading in SBVR.  By formulating a fact type reading it becomes possible to communicate the contents of a diagrammatical or report representation in a manner suited to a specific audience.  The fact type reading that can be formulated based on the sentences listed in Tables 1 and 2 is given below and is assigned the number 1.

1:  Operating country <Country> uses the business currency <Currency>.

This fact type reading has been derived by generalization of five example sentences, or facts.  By filling in the placeholder <Country> with the name of an actual operating country (e.g., "Germany"), and the placeholder <Currency> with the name of a business currency (e.g., "Euro"), we obtain a concrete sentence or fact, in this case one of the sentences we started with.

Each placeholder of a fact type reading has a counterpart in a fact type, and this counterpart is called 'role' in SBVR.  This counterpart is shown in Figure 3 in a diagrammatical form, using a NIAM2007 representation.  In the diagrammatical representation of a fact type, i.e., the fact type diagram, a role is represented by a rectangle containing the name of the role.  This diagram also contains the fact type reading.  In such diagrams, it is advised to include a sample population of ground facts.  In this case, five different pairs of variable elements are filled into the pair of roles, as population of the fact type.

Figure 3.  Provisional fact type diagram with population

Every fact instance verbalization is given a unique number followed by the symbol ')'.  The fact instance verbalizations are generated, based on the values in the population of the fact type diagram 'OperatingCountry' in Figure 3.

Every fact type reading is given a unique number or code, in this case the number 1, within the domain-specific component of the conceptual schema.  Every fact type is given a name, in this case 'OperatingCountry' as well as a shorter code (here:  OC) to facilitate communication.

The fact to be generated from the first record below the roles in the fact type diagram (which is the first record of the population) and the fact type reading, can be read as follows:

Operating country Germany uses the business currency Euro.

Regarding the structural understanding of the world (or the semantics) of these kinds of fact examples, at least the following terms have to be defined as concept definitions in this domain-specific conceptual schema:

Table 3.  Concept definitions of an example domain-specific conceptual schema

Above, we used a concrete graphical example in which the relevant ground facts are represented in a diagrammatical manner.  We verbalized these diagrammatical representations of ground facts to get textual representations of the same facts.  We made a start in transforming each textual representation into a domain-specific conceptual schema.  Until now this transformation has resulted in:

1. two concept definitions;
2. one fact type diagram, as a possible representation of the fact type;
3. one fact type reading.

These three knowledge classes are only a part, although a very important basis, of the desired domain-specific conceptual schema.  We therefore have to continue specifying the additional parts of the conceptual schema.  We proceed in a structured way to the next part of the conceptual schema, the so-called constraints (a class of business rules).

What is a constraint?  A constraint is a rule that limits the populations of the fact types and its population transitions, allowing only populations and transitions considered meaningful.  According to NIAM2007, the most important constraint or business rule is the uniqueness constraint, the specification of which is illustrated in the process in the following section.  A uniqueness constraint corresponds to the set of independent variables of a function, a major concept in mathematics.

3.  The Process of Specifying a Uniqueness Constraint

To derive constraints, it is advised to use a precise process for systematic specification.  As uniqueness constraints are the major constraints, we first derive these.  Processes for other constraints will be discussed in future columns.  The precise process ensures that all questions that need to be posed to a business domain expert are systematically composed and expressed in the familiar jargon of the business professional.  The result of those processes leads to the following question to the subject matter expert in a language readily understood by the business domain expert:

Is it possible that the following two sentences can exist at the same time in the fact population?

Operating country Germany uses the business currency Euro.

and

Operating country Germany uses the business currency USD.

Or, as recommended by NIAM2007, use the format that is familiar to the domain expert and ask:  "Are the contents of Figure 4 acceptable to you?"

Figure 4.  Concrete not permitted business example

The business domain expert will clearly say "No."  It is not allowed for an operating country to use two or more different business currencies as specified in line 5 of EU-Rent Use case 1.2.  This answer is shown diagrammatically in the fact type diagram in Figure 5.

Figure 5.  Matrix method for uniqueness: forbidden (x) combination of records

Based on this particular answer from the business domain expert it is possible to conclude that the name of a country can only appear once in the fact population below the role 'Country' of fact type diagram 'OperatingCountry'.  This results in the situation that the name of a country is unique within this fact population.  In a fact type diagram in NIAM2007 a uniqueness constraint is indicated by a solid line with an arrow at both ends.  In Figure 6, the uniqueness constraint, arbitrarily named 'pk23' as the signifier of a primary key, is added to the fact type diagram 'OperatingCountry'.

Figure 6.  Fact type diagram 'OperatingCountry', after addition of uniqueness constraint 'pk23'

What are the operational semantics of a uniqueness constraint?  Every uniqueness constraint arrow means:  below me in the fact population no duplicate values or signifiers can occur.

To know if a uniqueness constraint holds for the second role named 'Currency', one has to ask the business domain expert whether or not the following two facts can appear at the same time in the fact population:

Operating country Germany uses the business currency Euro.

and

Operating country France uses the business currency Euro.

The business domain expert will say, "Yes, this was already clear in Figure 2."  It is indeed possible that France as well as Germany use the same business currency; please note that this was represented in the data use case of Figure 2.  So the use of a specific business currency is not unique in this fact population.  This implies that the values under the role 'Currency' are not unique in this fact population and therefore no uniqueness constraint applies to this particular role of the fact type.

Figure 7.  Intermediate result: no uniqueness constraint on Currency role

In Table 4 an overview diagram of the procedure mentioned above is given.

Table 4.  The register of answers given by the domain-specific expert

The use of easily recognizable symbols in NIAM2007 fact type diagrams, like traffic-signs, makes communication about a conceptual schema more productive.  In addition to the uniqueness constraint symbol introduced above, Figure 8 introduces the following symbols: 

• the value rule symbol (curly brackets {} in a circle),
• the data type symbol (a character or character combination in the left upper corner of a role's rectangle), and
• the non-empty rule symbol (a black rectangle in the right lower corner of a role's rectangle).

A value rule limits the values that can be used to fill in a particular role to a given list of possible values (listed at the bottom of the fact type diagram for representational purposes).  In our use case we know that there is a limited number of operating countries for EU-Rent:  USA, France, UK, Germany, and Italy.  Others do not exist, thus should not be recorded, which is prescribed by value rule 'val5003'.

A data type limits the possible values of a particular role to values of a specified type.  In the OperatingCountry fact type in Figure 8, all values are allowed by the data type 'c' which is an abbreviation for 'character'.

A non-empty rule forbids a role to be left empty in a record.  As SBVR only deals with elementary facts, this rule is superfluous.  However, in NIAM2007 we also use optimally combined fact types and then the mandatory or optional rule is necessary.  In the fact type OperatingCountry this is true for both roles, as it is not allowed to record an operating country without recording the corresponding business currency and vice versa.  The latter is implied by the uniqueness constraint 'pk23' and the former is indicated by the non-empty rule symbol in the Currency role.

Figure 8.  Complete fact type diagram OperatingCountry

4.  Summary and conclusions

SBVR is a major breakthrough for requirements engineering as well as structured knowledge management.  For the first time since IT started about half a century ago there is a prestigious group, OMG, that has combined the strengths of natural and formal languages and has eliminated the weaknesses in the combination.  Chapeau!  SBVR is solidly based on formal logic, while at the same time permitting an understandable variation of predicate logic in the form of Structured English.  SBVR includes concept definitions as first class citizens, a major step forward.  SBVR uses only one data structure, the elementary fact type, another major step forward.^[2]  SBVR uses fact type readings to facilitate effective communication.  A third major step forward.  SBVR provides the understandable logic-based Structured English to specify constraints and derivation rules.  A fourth major step forward.

SBVR makes it possible for the first time that an essential requirement of CMMI^[1] is met, namely understandability to all stakeholders.^[6]

IT has suffered — needlessly — for too long not having an SBVR.  Too many times controlled natural language was rejected by the extreme formalists.  John Sowa says it clearly in [11]:  " … every step of every proof in any formal logic can be translated to an argument in ordinary language that is just as correct and cogent as the formal version."

SBVR invites parties to specify other languages, e.g., diagrammatic or text-based or a combination that has the same expressive power of SBVR.  In this column we will gradually describe such a diagrammatic language that, solidly based on logic and linguistics, has been tested and improved for over 35 years in business practice.

SBVR invites parties to supply a methodology to derive an SBVR domain-specific schema.  In this column we have described the process of deriving the most important business rule, viz. the uniqueness constraint.  We strongly recommend to always specify the uniqueness constraint first, before any other constraint.  In fact, in our best practice for developing a requirements specification expressed in SBVR we strongly recommend not to accept a fact type without the uniqueness constraints, as it is our experience that the absence of uniqueness constraints is a major polluter and consequently has a very bad effect on productivity.

It is our conviction that we are at the brink of a major increase in knowledge worker productivity if SBVR were to be used as the Common Knowledge Language.

References

[1]  Carnegie Mellon, Software Engineering Institute, CMMI Product Team, CMMI for Development, version 1.2, August 2006, p. 410.

[2]  Chapin, Donald & Hall, John, Semantics and Business Rules, Presentation at Semantic Technology Conference, San Jose, California, March 2006, sheet 26.

[3]  Halpin, Terry, Information Modeling and Relational Databases, Morgan Kaufmann, San Francisco (2001).

[4]  Halpin, Terry, Fact-Oriented Model-Driven Development, paper presented at Conference Information Systems:  The Next Generation, HAN University, The Netherlands (2007).

[5]  Hendryx, Stan, "OMG Business Rules Proposal Nears Completion," Business Rules Journal, Vol. 6, No. 2 (Feb. 2005), URL:  http://www.brcommunity.com/a2005/b226.html

[6]  Morgan, Tony, Business Rules and Information Systems:  Aligning IT with Business Goals, Addison-Wesley, Boston (2002).

[7]  Nijssen, Sjir, "A Framework for Discussion."  In:  ISO/TC97/SC5/WG3 and comments on 78.04/01 and 78.05/03 (1978).

[8]  Nijssen, Sjir, "SBVR:  Semantics for Business," Business Rules Journal, Vol. 8, No. 10 (Oct. 2007), URL:  http://www.BRCommunity.com/a2007/b367.html

[9]  OMG, Semantics of Business Vocabulary and Business Rules (SBVR), First Interim Specification, Mar. 2006.  Available as dtc/06-03-02 at http://www.omg.org.

[10]  Ross, Ronald, Principles of the Business Rules Approach, Addison-Wesley (2003).

[11]  Sowa, John F., "Fads and Fallacies about Logic," IEEE Intelligent Systems, 22:2, pp. 84-87, (March 2007).  URL: http://www.jfsowa.com/pubs/fflogic.htm

# # #