| [mdt-sbvr.dev] A proposal for modeling Concepts and related aspects |
My past work on a prototype SBVR tool has been implemented with what I'm
calling here the "conventional approach" to modeling in EMF SBVR's
"concept" and related features. This "conventional approach" is basically
what's been proposed in this MDT-SBVR work, so far. My experience is that
representing an SBVR vocabulary this way produces an explosion of instances
of EMF classes. This note proposes an alternative design. The advantage I
see in this alternative is a simplification of the EMF model of SBVR, and a
substantial reduction in the number of object types and object instances
that an SBVR tool must manage.
I've attached several images of UML diagrams. The first one shows a
"conventional" UML model of part of SBVR's metamodel. This is nowhere near
complete, and includes some minor simplifications -- but it shows the idea.
Each concept in SBVR becomes a class in UML and EMF.
(Embedded image moved to file: pic28476.jpg)
The next image shows a fragment of an SBVR vocabulary that defines concepts
"driver", "car", "driver owns car", and one instance of each. As you can
see, an SBVR tool done this way has to manage a lot of separate object
instances.
(Embedded image moved to file: pic09845.jpg)
The third image summarizes the alternative approach that I am proposing.
The idea is to implement some of the "meaning" aspects of SBVR as extended
forms of the corresponding EMF classes. For example, SBVR's "concept"
would inherit directly from EMF's EClass, and add attributes and operations
to support SBVR aspects such as "Representation". In a sense, we would
extend EMF itself to represent the equivalent concepts in SBVR. We would
implement other SBVR concepts (e.g. "Expression") in the conventional way.
(Embedded image moved to file: pic04563.jpg)
The final image illustrates how the same "car", "driver", "driver owns
car", and instances thereof would look using my proposed alternative
("EMF-extension") approach. (There's an instantiation connection missing
from the diagram, between the "Driver owns Car" link and the "Binary Fact
Type" class. This is because UML doesn't support the kind of instantiation
that I am trying to show.)
Imagine a user of an SBVR tool creates a new vocabulary entry "Driver".
The tool would represent "Driver" via a dynamically-generated
"Concept" (i.e. an "EClass"). The tool would also create a
"Representation" and an "Expression" as instances of predefined EMF
classes. It would use operations on "Meaning" to create the link from the
"Driver" Concept to the new "Representation".
Now imagine the user creating the fact type "Driver owns Car". The tool
would dynamically create a "Binary Fact Type" (i.e. an EMF "EReference")
between "Driver" and "Car". It would then create the "Driver owns Car:
Representation" instance and corresponding "Expression" instance and invoke
operations on the "Meaning" to associate the "Representation" to the
"Binary Fact Type"..
Now imagine further that the tool user creates an instance "Bill" of
"Driver", an instance "Car123" of "Car", and an instance "Bill owns Car123"
of the fact type "Driver owns Car". The tool would create instances of the
"Driver" and "Car" EClasses, and would link the instances to represent
"Bill owns Car123". As you can see in the image, the result has many fewer
object instances than above. By directly representing some SBVR concepts
in EMF, this approach eliminates a modeling level and drastically
simplifies what a tool has to do.
Note that the model has several instances where associations cross between
modeling levels: "Car" and "Driver" would be realized as regular EClasses
in EMF. "Car:Representation" is an instance of a "Representation" linked
to the EClass "Car". Similarly, the instance-level link "Bill owns Car123"
is connected to the model-level information captured in the corresponding
Representation. We would handle these cross-modeling-layer connections via
extensions of EMF implemented as attributes and operations of the interface
"Meaning".
In this example, the instance link "Bill owns Car123" models an Atomic
Formulation that is based on "Driver owns Car" and is bound to the
individual concepts "Bill" and "Car123". Of course, AtomicFormulations can
also bind to expressions and variables. Expressions are just instances of
an EClass "Text", so they fit into this scheme easily. Similarly, SBVR
variables should be represented as instances of an EClass "Variable". That
is, each Quantification or Projection would introduce or project an
instance of "Variable" that participates in one or more Atomic
Formulations. Our implemention of "Variable" would have to "know" how to
model all the Atomic Formulations (ie EReferences / ELists) in which
Variable instances participate. That may be an interesting programming
challenge, but should be doable.
There's much more to this idea, but I think this captures the basic scheme,
and illustrates the significant reduction in the number of instance objects
that have to be maintained by an SBVR tool implemented this way. Of
course, there is a cost: this involves an extension of EMF itself. But
there are potential further advantages: EMF has no way to model n-ary fact
types and objectifications. If we are willing to extend EMF, then we
could add also support for those and further simplify an SBVR tool.
Comments?
(Embedded image moved to file: pic19424.jpg)
--------------------------------
Mark H. Linehan
STSM, Model Driven Business Transformation
IBM Research
phone: (914) 945-1038 or IBM tieline 862-1038
internet: mlinehan@xxxxxxxxxxAttachment:
pic28476.jpg
Description: JPEG image
Attachment:
pic09845.jpg
Description: JPEG image
Attachment:
pic04563.jpg
Description: JPEG image
Attachment:
pic19424.jpg
Description: JPEG image
