SBVR for UTP — Using an OMG Specification to develop another OMG Specification

Markus   Schacher
Markus Schacher Co-founder and KnowBody, KnowGravity Inc Read Author Bio || Read All Articles by Markus Schacher

This article describes how the OMG specification "Semantics of Business Vocabulary and Business Rules" (SBVR) has been pragmatically applied to develop another OMG specification, the "UML Testing Profile" (UTP).  As a language to express business rules for business people, the business in this case is rather technical:  it is the business of testing complex systems.  Nevertheless, in the endeavor of developing UTP, SBVR has been used to define the semantics of the core "business concepts" of testing as well as some of the core "business rules" of this domain.

The UML Testing Profile

Back in 2005 the initial version of the UML Testing Profile (UTP) was published by the OMG (Object Management Group).  The motivation of the authors was to provide a standard language for designing, visualizing, specifying, analyzing, constructing, and documenting the artifacts of test systems.  As its name indicates, the UTP was designed as a UML profile (a customization mechanism of the UML [UML]) to provide a domain-specific language specifically designed to formalize artifacts typically required in the testing domain.

Although dedicated books such as [MBT] have been published, that version of UTP did not get widely known and used in practice since not many people understood what UTP really was about:  some people at the OMG even believed that the UTP was some kind of mechanism to test the UML.  Thus, in June 2010 the UTP 1.1 Revision Task Force (RTF) was chartered with the intention to improve the visibility and comprehensibility of the UTP and to adapt it to the latest development in the Model-based Testing domain.  Even at that time the group of UTP developers had the vision to develop a major revision (UTP2) by developing several intermediate minor revisions.  As a result of this, in June 2011 UTP 1.1 was released and, in August 2012, UTP 1.2.  In September 2012 a Request for Information (RFI) was issued to gather requirements from the industry on the forthcoming major revision UTP2.  An initial submission of the new UTP2 was submitted to the OMG in May 2014 and currently a 2nd revised submission is expected for the end of 2015.

Semantics of Business Vocabulary and Business Rules

In 2003 the OMG issued a Request for Proposal (RFP) called "Business Semantics of Business Rules" (BSBR).  The vision was to standardize the semantics and representation language for business rules specifically for business people.  The specification was supposed to be compatible with the Business Rules Approach as summarized in the "Business Rules Manifesto" [BRM], published by the Business Rules Group.  One of the essential requirements of this specification was that the business rules be stated in terms of a business vocabulary — "the shared understanding among business people of the things they have to deal with to run the business and the language they use to talk about them with each other."  Furthermore, the specification was to be based on formal logic (mainly predicate logic) to achieve a solid precision of the semantics of business rules.

As a response to this RFP, and after several iterations, in January 2008 the first version of "Semantics of Business Vocabulary and Business Rules" (SBVR) was published by the OMG.  Since then, SBVR has undergone several minor revisions of which the latest — SBVR 1.3 — was released in May 2015.  One outstanding feature of SBVR is that SBVR is specified in itself, i.e., the entire specification of SBVR is specified in SBVR.  Furthermore, SBVR supports different rule languages to represent SBVR rules, such as "SBVR Structured English" (SBVR-SE) and RuleSpeak® [RS].  Based on SBVR, in August 2013 a dedicated specification defining important cross-domain concepts and rules related to date and time [DTV] was published that supports complex temporal aspects of business rules including support for different calendars, time zones, etc.

Defining Meanings:  The Conceptual Model

One of the core artifacts of the UTP2 is the conceptual model that defines the semantics of important test concepts.  In 2013 the UTP2 working group decided to define this conceptual model as an SBVR model.  So, the task was to define the meaning of concepts such as:  "what is a test case?" "what is a stimulus?" and "what is a test requirement?"  However, we decided to apply SBVR in a rather pragmatic form and not to follow the specification in a word-by-word manner. 

When defining a vocabulary as the foundation of a conceptual model, SBVR distinguishes two major types of concepts:

  • Noun Concepts are concepts that represent the meaning of a noun or noun phrase.

  • Verb Concepts are concepts that represent the meaning of a verb phrase that involves one or more verb concept roles.

In SBVR, such concepts may be represented in textual form and/or in graphical form on so-called "Concept Diagrams."  Concept Diagrams resemble UML class diagrams but have some important differences:

  • Rectangles represent domain-level noun concepts rather than classes of a software system.
  • Lines between rectangles represent verb concepts rather than associations.
  • Verb concepts have no multiplicity, like associations do in UML, as multiplicities are a form of rules.
  • Verb concepts may not only connect two noun concepts (binary verb concepts) but any number of noun concepts (including only one noun concept in the case of unary verb concepts).

The conceptual model of UTP2 has been structured into multiple vocabularies, each representing a sub-domain of testing such as "Test Cases," "Test Data," or "Test Configuration," etc. which we will largely ignore here.  To illustrate the use of SBVR in the development of UTP, we will focus on the UTP2 vocabulary "Test Actions" that defines the semantics of atomic actions (called "test actions" in UTP2) of a test specification.  Figure 1 is part of this vocabulary, and the Concept Diagram shown visualizes its core concepts.

Figure 1.  A Concept Diagram  

As one can see, a "test action" is an "atomic procedural element" which in turn is a "procedural element."  Furthermore, there are several sub-categories of "test actions" such as "create stimulus action" or "expect quiescence action."  There are also a number of binary verb concepts such as "leads to" (in "procedural element leads to test action verdict") as well as even more complex verb concepts such as "create stimulus action sends stimulus to test item" which combines three noun concepts into a single phrase.

However, just drawing a Concept Diagram is not sufficient to define the semantics of those concepts.  After all, what does "test action" mean?  To define individual concepts, SBVR strongly suggests the use of so-called "intentional definitions."  The form of an intentional definition has been standardized by ISO (see [ISO1], [ISO2]) by the following intentional definitions [taken from [ISO1]]:

intentional definition:

A definition (3.3.1) which describes the intension (3.2.9) of a concept (3.2.1) by stating the superordinate concept (3.2.13) and the delimiting characteristics (3.2.7).

The numbers shown in parentheses in the above definition are just references to other definitions (e.g., "intension" is defined in section 3.2.9).  This form of definition has the advantage that it very concisely describes the essence of a concept.  However, it is usually not so easy to create such definitions (and it is even harder to find a consensus on those definitions). 

Figure 2 lists the intensional definitions of some of the noun concepts shown in Figure 1.

test action:

An atomic procedural element that is an instruction to the tester that needs to be executed as part of a test case within some time frame.

create stimulus action:

A test action that instructs the tester to submit a stimulus (potentially including test data) to the test item.

stimulus:

A set of test data that is sent to the test item by its environment (often to cause a response as a reaction) and that is typically used to control the behavior of the test item.

Figure 2:  Some Noun Concept Definitions

However, not only the semantics of noun concepts but also the semantics of verb concepts may be precisely specified.  Figure 3 lists some examples of verb concepts shown in Figure 1.[1]

procedural element leads to test action verdict:

At the end of executing a procedural element, the test action verdict is set according to the outcome of the procedural element.

time point is specified as procedural element:

The time point that is the earliest point in time when the procedural element may be executed.

expect quiescence action does not expect response from test item:

The tester is instructed by the expect quiescence action to verify that one or more particular responses are not emitted by a particular test item within the duration specified by the procedural element.

Figure 3:  Some Verb Concept Definitions

Finally, the Concept Diagram in Figure 1 also includes two noun concepts adopted from the Date Time Vocabulary [DTV]:  the noun concepts "duration" and "time point."  By means of the verb concepts "is specified as" and "is actually started at" — as well as the roles "earliest start" and "latest start" of a "time point" — we may express that any "test action" must be executed within some timeframe.  This is where rules come into play.

Rules

SBVR distinguishes two main types of rules:  "definitional rules" (also called "structural rules") and "behavioral rules" (also called "operative rules").  Both types of rules are sentences formed from concepts defined in a vocabulary.  Definitional rules, as their name says, contribute to the semantics of concepts by expressing constraints on them:  what is possible, what is impossible, and what is necessary to have a consistent model.[2]  Figure 4 lists some examples of definitional rules related to the Concept Diagram shown in Figure 1.[3]

SRTA01:  It is necessary that a create stimulus action sends exactly one stimulus.

SRTA04:  It is necessary that a check response data action checks at least one response against the test data.

SRTA06:  It is necessary that the time point that is specified as "earliest start" of the test action is before or at the same time as the time point that is specified as "latest start" of the procedural element.

Figure 4:  Some Definitional Rules

In contrast to definitional rules, behavioral rules do not constrain models expressed in a vocabulary-based language, but they constrain the behavior of the people in the world described by the vocabulary.  Compared to the constraints expressed by definitional rules, constraints expressed by behavioral rules are "softer":  they are prescriptions that may be violated by people, so they need to be enforced in one way or another.  In SBVR, behavioral rules are typically expressed by a sentence lead-in that is one of the following phrases:

  • It is obligatory that <some statement>.
  • It is permitted that <some statement>.
  • It is prohibited that <some statement>.

As mentioned above, in UTP2 every "test action" must be performed within a particular timeframe:  this is nothing else than an obligation on the testers.  This obligation may well be expressed by SBVR behavioral rules as shown in Figure 5.

OR201:  It is prohibited that a procedural element is actually started at a time point that is before the time point that is specified as "earliest start" of that procedural element.

OR202:  It is obligatory that a procedural element is actually started at a time point that is before or at the same time as the time point that is specified as "latest start" of that procedural element.

Figure 5:  Some Behavioral Rules

In the context of UTP2, these behavioral rules are not really part of the UTP2 specification.  However, they influence or guide the behavior of a tester responsible for executing a test specification expressed in UTP2.  If she or he fails to meet these obligations, the result of the test will be undefined or even unusable.

Communities

Another important notion of SBVR that helps to find consensus on vocabularies is the notion of a "Community."  SBVR distinguishes two types of communities:

  • A Semantic Community is a community whose unifying characteristic is a shared understanding (perception) of the things that they have to deal with.

  • A Speech Community is a subcommunity of a given semantic community whose unifying characteristic is the vocabulary and language that it uses.

In the context of UTP2, "Testers" could be considered as a semantic community as they deal with a common set of concepts relevant in the testing domain.  However, since not all testers speak the same language, different speech communities must be distinguished as well.  The terminology used to express the UTP2 conceptual model has been defined by OMG's "UTP2" community, i.e., the people involved in the development of the UTP2 specification.  However, there are also other important testing communities such as the people behind the ISO or ETSI standards for testing (see [ISO3] and [ETSI]).  These communities utilize (at least partially) the same concepts but use, for some of those concepts, different terms.  The following table illustrates some of the differences and similarities in the terminology used by these communities:

UTP2 Testers

ISO Testers

ETSI Testers

arbitration specification

pass/fail criteria

verdict arbitration

test case log

test execution log

?

test case verdict

test result

test verdict

test configuration

test environment

test configuration

test data

test data

mappable data element

test execution schedule

test procedure

?

test item

test item

system under test

test objective

test condition

test objective

test set

test set

test suite

test case

test case

test case

test procedure

?

test behavior

The table shows some total agreement among those communities (e.g., term "test case"), some partial agreement (e.g., terms "test item" versus "system under test"), some total disagreement (e.g., terms "test case verdict," "test result," and "test verdict") as well as some homonyms that may cause confusion if members of different speech communities talk to each other (e.g., term "test procedure" that has a different meaning in the "UTP2 Testers" speech community than in the "ISO Testers" speech community).  It also shows that some of the terms seem not to have an equivalent underlying concept in some of the communities (e.g., "test procedure").

Summary

This article has shown how the semantics of the terms used in a particular business may be formalized by means of the "Semantics of Business Vocabulary and Business Rules" (SBVR) specification of the OMG.  Specifically, it has illustrated how SBVR has helped to formalize the core concepts of the "UML Testing Profile" (UTP) specification of the OMG that is the "business" of testers.  SBVR may not only be used to formalize the semantics of those concepts by intensional definitions, concept diagrams, and definitional rules, but can also guide the behavior of people acting in a particular business domain — in our example the testers — by means of behavioral rules.

Notes

[1]  You may wonder about the colors used in these definitions.  These are defined by a syntax called "SBVR Structured English" which is part of the SBVR specification and which defines styling conventions for different concept types.  return to article

[2]  By "model" I mean here any description of a concrete aspect of the world by utilizing the language defined by an SBVR vocabulary, i.e., the noun concepts and verb concepts of that vocabulary.  return to article

[3]  SBVR Structured English defines a set of keywords that are styled in red in formalized SBVR rules.  return to article

References

[BRM]  The Business Rules Group:  The Business Rules Manifesto Version 2.0, November 2003, www.businessrulesgroup.org/brmanifesto.htm

[DTV]  Object Management Group:  Date-Time Vocabulary (version 1.0), formal/2013-08-01, August 2013.

[ETSI]  European Telecommunications Standards Institute (ETSI):  Methods for Testing and Specification (MTS); The Test Description Language (TDL); Specification of the Abstract Syntax and Associated Semantics, ETSI ES 203 119 V1.1.1 (2014-04), April 2014.

[ISO1]  International Organization for Standardization:  Terminology work — Vocabulary — Part 1:  Theory and application (First Edition), ISO 1087-1:2000(E), 2000-10-15, October 2000.

[ISO2]  International Organization for Standardization:  Terminology work — Principles and methods (Third edition), ISO 704:2009(E), 2009-11-01, November 2009.

[ISO3]  International Organization for Standardization:  Software and systems engineering — Software testing — Part 1:  Concepts and definitions (First Edition), ISO 29119-1:2013(E), 2013-09-01, September 2013.

[MDT]  Paul Baker, Zhen Ru Dai, Jens Grabowski, Ina Schieferdecker, Clay Williams:  Model-Driven Testing:  Using the UML Testing Profile, ISBN-13:  978-3540725626, Springer, October 2007.

[RS]  Ronald G. Ross:  RuleSpeak® - Version 2.x, Business Rule Solutions LLC, www.rulespeak.com/en/

[SBVR]  Object Management Group:  Semantics of Business Vocabulary and Business Rules (version 1.3), formal/2015-05-07, May 2015.

[UML]  Object Management Group:  Unified Modeling Language™ (OMG UML) — version 2.5, ptc/2013-09-05, September 2013.

[UTP]  Object Management Group:  UML Testing Profile (UTP) — version 1.2, ptc/2012-09-13, September 2012.

# # #

Standard citation for this article:


citations icon
Markus Schacher, "SBVR for UTP — Using an OMG Specification to develop another OMG Specification" Business Rules Journal, Vol. 17, No. 1, (Jan. 2016)
URL: http://www.brcommunity.com/a2016/b842.html

About our Contributor:


Markus   Schacher
Markus Schacher Co-founder and KnowBody, KnowGravity Inc

Markus Schacher (markus.schacher@knowgravity.com) is co-founder and KnowBody of KnowGravity Inc. (www.knowgravity.com), a small but smart consulting company based in Zurich, Switzerland, and specialized in model-based engineering. As a trainer, Markus ran the first public courses on UML in Switzerland back in early 1997, and as a consultant he helped many large projects introducing and applying model-based techniques. As an active member of the Object Management Group (OMG), Markus is involved in the development of various modeling languages such as the Business Motivation Model (BMM), the Semantics of Business Vocabulary and Business Rules (SBVR), and the UML Testing Profile (UTP). He is co-author of three books on business rules, SysML, and operational risk, as well as a frequent presenter in international conferences.

Read All Articles by Markus Schacher

Online Interactive Training Series

In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.