[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [mdt-sbvr.dev] SBVR Metamodel
|
I would like to elaborate on five of the points that Mark Linehan makes:
1. simplifying the model
2. the "redundancy" he notes
3. representation of conceptualization decision concepts
4. navigation
5. tool metamodel
1. One way to simplify the model, and the project, is to approach it
incrementally by SBVR vocabulary, in this order:
Meaning and Representation Vocabulary (MRV)
Logical Formulation of Semantics Vocabulary (LFSV)
Vocabulary for Describing Business Vocabularies (VDBV)
Vocabulary for describing Business Rules (VDBR)
SBVR Vocabulary (SBVR)
These are the compliance points of the SBVR spec. Some tools will comply
only with some compliance points. Our tool needs to be able to produce
models that are limited to the vocabulary of a specified compliance point,
so the models can be interchanged with tools that are limited to that
compliance point. By building the tooling as above, we can assure this will
be the case, that terms not in a vocabulary do not get mixed in, making the
produced model non-interchangeable.
Each vocabulary should be in its own UML and Java package, with the packages
related by package merges as shown in Fig. 2.1 of the spec, p.4. MRV is the
core. All of the other vocabularies depend on it. It is only about 25% of
the total. It can be used on its own for capturing vocabularies, thessauri,
and such. By doing MRV first, by itself, we make our lives easier, produce a
more useful and robust tool, and sooner than doing it all at once. Four or
five smaller releases instead of one big one.
2. Some of the "redundancy" Mark notes represents objectifications of fact
types: an instance of the objectification is an instance of the fact type.
Objectifications correspond to association classes in UML. Objectification
enables one to make assertions about a relationship of two objects.
Objectifications are not necessarily redundant, if there are other
predicates of the objectification. For example, "man is married to woman"
can be objectified as "marriage", which allows us to say things about the
marriage, like when and where it took place, who officiated, etc. A pattern
for definitions of objectifications is "marriage: actuality that a man is
married to a woman." Removing some such "redundancies" or factoring concepts
out of the tool metamodel can change the meaning of the SBVR metamodel.
Consider the case of "variable." A variable is a kind of bindable target. A
quantification is not a bindable target. Subsuming "variable" into
"quantification" is tantamount to saying "variable is a quantification"
rather than "quantification introduces variable." These two fact types do
not mean the same thing. The other predicates of "variable" need to be
respected: variable ranges over concept, logical formulation restricts
variable, variable is unitary, variable is free within semantic formulation,
projection is on variable, projection has auxiliarly variable, variable has
projection position, variable maps to fact type role. One cannot substitute
"quantification" for "variable" in all of these fact types and still have
the same meaning. For example, "variable is free within semantic
formulation." By definition, a variable that is free is a variable that is
not bound to a quantifier, i.e. it is not part of a quantification.
Substituting "quantification" for "variable" here leads to a contradiction -
it is a quantification and it is not. We need to make certain that such
proposed transformations of the metamodel are logically sound. There may be
some that are, and some that are not. Look at all the fact types involving
the concept before factoring it out.
3. The conceptualization decision concepts, 11.1.4, are conveniently
represented in the tool as are unary fact types. This is objectification in
reverse, using a fact type that corresponds to an object type. Since an
object in UML and Java can have only one base class, having an object that
is at once, for example, an object type and a concept of thing as composite,
is problematic in UML and Java (but not in English). Instead, assert the
characteristic "concept is concept of thing as unitary" of the concept in
the tool.
4. SBVR has a concept of navigation: in SBVR, all data is assumed to be
always accessible and all relationships are assumed to be navigable in each
direction. I mean the UML sense of "navigation," which merely means that it
should be "easy" to navigate. Assigning association ends to classes
certainly makes navigation easier in code, but is not the only way. I have
found that business people have clear notions of navigation. Confronted with
a line item of particular interest, it would be natural for a business
person immediately to ask, "what order is it on?", as well as to want to ask
of an order, "what line items are on the order?"
Navigation in the tool should be based on what makes the tool easy to use
both to build a model and to query it. Tool design, for navigation or
otherwise, should not constrain the expressivity of SBVR nor violate any
SBVR necessities or definitions. One way to indicate desired navigation of
an SBVR model is to include in the model questions that are queries the
business people want to make, and make statements about the sequence in
which they want to provide information -- for example they may want to
record the line items before recording the order details, because that works
better in their interactions with their customers. Such questions are
themselves rules (requirements): "The system must be able to answer within 1
second the question, "what order is a given item on?"" This is an obligation
claim that embeds a question.
5. Mark wrote:
> we should design a custom UML / EMF model for SBVR
> that is inspired by, but does not start with, the SBVR CMOF.
I agree. The tool is not the same thing as a fact model it produces, so we
would not expect its metamodel to be the same.
Stan Hendryx
Hendryx & Associates
Sunnyvale, California
USA
phone: +1 408 773-8089
email: stan@xxxxxxxxxxxxxxxx
> -----Original Message-----
> From: mdt-sbvr.dev-bounces@xxxxxxxxxxx
> [mailto:mdt-sbvr.dev-bounces@xxxxxxxxxxx] On Behalf Of Mark H Linehan
> Sent: Wednesday, April 23, 2008 12:47 PM
> To: mdt-sbvr.dev@xxxxxxxxxxx
> Subject: [mdt-sbvr.dev] SBVR Metamodel
>
>
> 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
>
> _______________________________________________
> mdt-sbvr.dev mailing list
> mdt-sbvr.dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mdt-sbvr.dev
>
