[mdt-sbvr.dev] SBVR Metamodel

[Mark H Linehan <mlinehan@xxxxxxxxxx>]

As has already been noted on the WIKI, the CMOF metamodel of SBVR does not
use composition,  does not indicate navigability across associations, and
does not specify aggregation in many cases where aggregation may be
desirable.  This is because SBVR was defined "in terms of itself".  That
is, the SBVR metamodel is defined using Structured English and the concepts
of SBVR itself, and then separately transformed into CMOF per clause 13 of
the SBVR specification.  So what we see in the CMOF metamodel is derived
from what is in the Structured English description of SBVR "in terms of
itself".

SBVR employs a modeling methodology called "fact modeling" or "fact
orientation".  This approach emphasizes fact types as being first class
concepts, on a par with nouns.  When mapping from SBVR concepts to UML
concepts, SBVR fact types are the equivalent of UML associations, and SBVR
nouns map to UML classes.  So "fact orientation" really amounts to treating
associations as peers of classes, in contrast to object orientation, where
the classes are supreme.

Clause 11.1.5 provides a categorization of fact types as "associative",
"property-of", "partitive", "specialization", or "assortment".  One can
apply these to specific fact types to indicate that they have (for example)
partitive semantics ("... a given part is in the composition of a given
whole").  For example, categorizing a fact type "order contains line items"
as "partitive" might imply an aggregation relationship.  Unfortunately,
none of the SBVR metamodel fact types are categorized using clause 11.1.5.
We might want to ask the SBVR RTF to apply clause 11.1.5 categorization to
the SBVR metamodel itself, especially if we made the corresponding UML
semantics explicit.

SBVR does not define anything equivalent to UML composition or navigation.
This is because these are programming concepts that are not meaningful to
business people.  You wouldn't expect business users to be able to answer a
question such as "given a line item, can I find the corresponding order?"
They probably wouldn't understand the question.  SBVR tries to model what
business people understand, so it omits these concepts.

In my experience, the "right" composition and navigation semantics for the
SBVR metamodel depends upon various aspects of the tool design.  For
example, one might expect that the association between a rule and a logical
formulation should be a composition relationship.  But, in my tool, I have
a wizard that shows users a list of possible logical formulations.  When a
user selects from the list, the selected formulation remains in the list
but is also shown in a rule.  So either the formulation must be cloned or
the association from rule to formulation must be aggregation rather than
composition.  My point is that only programmers know these details;
business modelers can't possibly provide this information.

The clause 13 transformation treats the fact type "x has y" as a
specification of a class/attribute relationship.  For example, the fact
type "atomic formulation has role binding" shows up in the CMOF as a class
"atomic formulation" with an attribute "role binding".   This works fine in
many cases (example: "atomic formulation has role binding") but is
debatable in other cases (example: "logical operation has logical operand"
where both "logical operation" and "logical operand" are kinds of "logical
formulation").  Furthermore, the SBVR metamodel includes fact types other
than "x has y" that probably should be handled as class/attribute
relationships.  One example is "fact type form incorporates fact symbol".

In my own partial SBVR implementation, I ran across at least some cases
where the SBVR metamodel has "redundant" classes.  For example, each
"atomic formulation" has a set of "role bindings", and each "role binding"
binds to a single "bindable target".   I found it simpler to model "role
binding" as one end of an assocation between "atomic formulation" and
"bindable target".  I cannot find any value in modeling "role binding" as
its own class.  Similarly, the SBVR metamodel says that each
"quantification" introduces exactly one "variable", where a "variable" is a
kind of "bindable target".  After a couple of iterations of my prototype, I
dropped "variable" completely, incorporating its properties into
"quantification" and making "quantification" a kind of "bindable target".
I have not yet implemented "projection", which also introduces a "variable"
-- but when I do, I expect to do the same thing: make "projection" have the
properties of a "variable", and also make "projection" another kind of
"bindable target".   The net result of dropping both "variable" and "role
binding" is a considerable simplification of that part of the model with no
loss of SBVR semantics.

My net: this project has already discovered that it can't use the SBVR CMOF
model exactly.  I go further: I think we should design a custom UML / EMF
model for SBVR that is inspired by, but does not start with, the SBVR CMOF.
This UML / EMF model should be simpler than the CMOF model, and should
clarify details that matter to tools but are not addressed in the CMOF.
Then we will need an importer and an exporter that converts between the
SBVR interchange file format (as defined by the CMOF) and the UML / EMF
model.
--------------------------------
Mark H. Linehan
STSM, Model Driven Business Transformation
IBM Research

phone: (914) 945-1038 or IBM tieline 862-1038
internet: mlinehan@xxxxxxxxxx