[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [mdt-sbvr.dev] Fw: A proposal for modeling Concepts and related aspects
|
Hi Mark,
Looks as an interesting idea to integrate EMF or EMOF native features
with the toolingmodel. Could you shed some light on how big the
reductions are likelly to be using this approach?
Could you also elaborate on how the new DataProperties, is property type
of fact, BinaryFactTypes, characteristics are "formally" integrated with
each other?
thanks
/anders
Mark H Linehan wrote:
***********************
Warning: Your file, sbvr.zip, contains more than 32 files after
decompression and cannot be scanned.
***********************
Over the last few months, I've had a summer intern -- Andrey Soares --
implement the proposal that I made back in May (attached, below). His
work is attached in a zip file that contains: /(See attached file:
sbvr.zip)/
* .ppt charts describing our design
* .doc file describing how to install and use his code
* two examples: sbvrModel.java and ECommerceModel.java
* UML model of his design: sbvr.emx, created using RSA v7
* corresponding sbvr.ecore EMF model
* source code and corresponding binaries, contained in internal zip
file called completeSBVR.zip
This implements the following aspects of the SBVR Meaning and
Representation Vocabulary using the "EMF extension" approach
summarized below and in Andrey's charts:
* Meaning
* Concept
* Noun
* Fact Type
* Characteristic
* Expression
* Text
* Representation
* Definition
* Informal Definition
* Dictionary
* Conceptual Schema
The advantages of this approach include: (a) simpler EMF model than
the "conventional" approach, resulting in fewer objects to be managed
by a tool; (b) elimination of 1 metamodel layer when implementing SBVR
on top of EMF; (c) instances are managed as individual objects, which
should simplify things if/when someone wants to implement an
instance-level reasoner.
This technique saves domain vocabularies in a file called <name>.sbvr
and instances in files called <name>.xml.
I suggest that this is the way to go for the M&R implementation.
Comments solicited.
--------------------------------
Mark H. Linehan
STSM, Model Driven Business Transformation
IBM Research
phone: (914) 945-1038 or IBM tieline 862-1038
internet: mlinehan@xxxxxxxxxx
----- Forwarded by Mark H Linehan/Watson/IBM on 08/20/2008 09:26 PM -----
*Mark H Linehan/Watson/IBM*
05/16/2008 03:23 PM
To
mdt-sbvr.dev@xxxxxxxxxxx
cc
Subject
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.
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.
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.
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?
--------------------------------
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