Re: [mdt-sbvr.dev] Some thoughts about using the EMF Extension approach

[Mark H Linehan <mlinehan@xxxxxxxxxx>]

Stan,

I annotated your original questions with responses like this.
--------------------------------
Mark H. Linehan
STSM, Model Driven Business Transformation
IBM Research

phone: (914) 945-1038 or IBM tieline 862-1038
internet: mlinehan@xxxxxxxxxx
"Stan Hendryx" <stan@xxxxxxxxxxxxxxxx>

"Stan Hendryx" <stan@xxxxxxxxxxxxxxxx>
Sent by: mdt-sbvr.dev-bounces@xxxxxxxxxxx

11/26/2008 02:43 AM

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

To	"'SBVR developer list'" <mdt-sbvr.dev@xxxxxxxxxxx>
cc
Subject	[mdt-sbvr.dev] Some thoughts about using the EMF Extension approach in an editing tool

Mark,
 
I’m trying to understand how you see the meta language and the object language represented in a modeling tool with the EMF Extension approach. I assume that the subclasses of EClass correspond to the meta language concepts, and instances of these subclasses correspond to object language concepts or things, i.e. what the user is modeling.

Mark: only a few SBVR concepts are modeled as subtypes of corresponding EMF concepts. All other SBVR concepts (e.g. Designation, Text, _expression_, etc.) are modeled using standard EMF techniques.  Standard EMF modeling techniques apply to everything in the other SBVR vocabularies (LFSV, VDBR, etc.).

 Since SBVR is the metamodel, and every entry in SBVR is a concept, this suggests that there will be a subclass of EClass for each SBVR concept. Is this how you see it? 

Mark: No.  (1) I want to use regular EMF modeling techniques for most SBVR concepts.  (2) Only Noun extends EClass.  Characteristic and DataProperty (binary fact type ranging over Text or Number) extend EAttribute.  ObjectProperty ("has" ranging over anything other than Text or Number) and BinaryFactType (other binary fact types) extend EReference.

For the SBVR concepts that are types of concepts (“concept” and its descendents), an instance is a concept and can itself be instantiated. For all other concepts, the instance is some kind of thing, identified in the tool by a reference scheme for the concept. Since all concepts in SBVR descend from “thing”, won’t it therefore be adequate just to make “thing” alone to descend from EClass? This should work well with the objectification of fact types, as I described in a previous email.

Mark: No, fact types are not kinds of classes and should not descend from EClass.

Reference schemes will play a very important role. Every SBVR concept will need a reference scheme, even those for which SBVR does not provide one; we will have to provide one for tools to use.

Mark: Yes, but how does this relate to your idea of "thing has URI"?

 We need to discuss how the necessities of SBVR are to be enforced in tools.

Mark: yes, this is an issue regardless of which approach we use.

Will we need to tailor the EMF code generator to process these kinds of models, to generate useful tool user interfaces and persist the models they edit?

Mark: the existing implementation successfully persists and loads SBVR vocabularies.  No special "tailoring" of the code generator was needed for that.  More work would be needed to get the EMF-generated editor to work, but it should be possible.  I don't think that that kind of editor is a "useful tool user interface".
 
Stan
 
 _______________________________________________
mdt-sbvr.dev mailing list
mdt-sbvr.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-sbvr.dev