RE: [mdt-sbvr.dev] Thoughts about two approaches to modeling the Meaning

[Mark H Linehan <mlinehan@xxxxxxxxxx>]

I will not be at the OMG meeting, but can participate by phone. I will be busy all day Tuesday and Thursday but can manage almost any other time.

Regarding comment (1): the EMF extension approach may complicate, but I doubt it prevents the use of other EMF frameworks. The EMF extension approach enables at least one aspect of EMF: the use of the EMF persistence framework to store and load individual constants.

Regarding comment (2): I think the learning curve is pretty steep either way, because in either case, tool developers have to figure out what classes to create and what relationships to build to represent the various aspects of the SBVR metamodel. I believe the solution to this is "higher-level" library functions that hide much of the detail of manipulating the metamodel. For example, here's what you have to do to create an object type "car" in the two approaches, if you write code that directly manages the EMF classes:

1. Create an ObjectType
2. Add it to the package as a packaged element.
3. Create a Designation.
4. Setup the relationshp between the ObjectType and the Designation.
5. Add the Designation to the package as a packaged element.
6. Create a Text.
7. Setup the relationship between the Text and the Designation.
8. Add the Text to the package as a packaged element.

At the lowest level, the work involved is almost exactly the same in the two approaches.  What's need to make this easier for tool developers is a higher-level library such as the one that Dave started in the "Operations" classes.  With that approach, the eight steps above are accomplished by a one-line method call.

Regarding use cases, I believe the "EMF extension" approach significantly helps with transformations to UML or implementation languages such as Java.  The reason is that the SBVR vocabulary gets stored directly as a set of EMF instances, thus taking care of some of the transformation decisions.
--------------------------------
Mark H. Linehan
STSM, Model Driven Business Transformation
IBM Research

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

"Dave Carlson" <dcarlson@xxxxxxxxxxxxxxx>

"Dave Carlson" <dcarlson@xxxxxxxxxxxxxxx>
Sent by: mdt-sbvr.dev-bounces@xxxxxxxxxxx

12/02/2008 11:45 AM

Please respond to
SBVR developer list <mdt-sbvr.dev@xxxxxxxxxxx>

To	"'SBVR developer list'" <mdt-sbvr.dev@xxxxxxxxxxx>
cc
Subject	RE: [mdt-sbvr.dev] Thoughts about two approaches to modeling the Meaning & Representation (MRV) part of SBVR

Mark, et al,
 
My apologies for not responsing to this thread sooner.  Some urgent personal matters required me to take off a week or so, and I am still digging out...
 
I will be attending the OMG meeting in Santa Clara, CA next week, arriving late Sunday and leaving Friday afternoon.  Mark and Stan, will you be there?  Kenn?  Can we plan a meeting to dicuss these design alternatives?  I am unavailable Tuesday afternoon and all day Wednesday next week; I must attend the Open Health Tools board meeting that is co-located with OMG (see www.openhealthtools.org).  If anyone has an interest in business modeling for healthcare (BPMN and SBVR), I would also like to discuss that.
 
Regarding Mark's comment below, my greatest concern about using the EMF extension approach is (1) prevents, or complicates, use of many other EMF frameworks for validation, search, editor generation, edit transactions, etc., and (2) more difficult learning curve that will prevent other tool developers and product vendors from using this metamodel implementation.
 
I believe that it is essential for us to summarize several use cases for end-user tooling that will be implemented on top of this SBVR tooling metamodel.  How do these decisions help or hinder creation of "structured english" editors and publishing tools?  Search and repository tools?  Transformation to/from UML, OCL, or other design models?  Transformation to/from OWL and ODM?  Transformation to/from the SBVR exchange metamodel and serialization format?  Other tooling use cases?
 
Dave

The principle downside I see with the EMF extension approach is the risk that future changes in EMF could break the MRV implementation. This risk arises from the fact that the implementation depends upon some aspects of the EMF design. On the other hand, the EMF design is pretty open, so it would be hard to change it in significant ways without breaking lots of other code.
--------------------------------
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