RE: [mdt-sbvr.dev] A proposal for modeling Concepts andrelated aspects

["Stan Hendryx" <stan@xxxxxxxxxxxxxxxx>]

Mark,

What about individual concepts? I've tried marking them as Leaf classes in
UML, stereotyping them <<individual concept>>, but EMF doesn't seem to do
anything special with leaves. Should they be singletons?

Stan


> -----Original Message-----
> From: mdt-sbvr.dev-bounces@xxxxxxxxxxx 
> [mailto:mdt-sbvr.dev-bounces@xxxxxxxxxxx] On Behalf Of Mark H Linehan
> Sent: Friday, May 23, 2008 5:53 AM
> To: SBVR developer list
> Subject: RE: [mdt-sbvr.dev] A proposal for modeling Concepts 
> andrelated aspects
> 
> Dave,
> We definitely need to do some experiments to understand the 
> ramifications
> of the approach that I proposed.  I have a summer intern 
> working with me
> for the next few months, and I will work with him to figure 
> out the answers
> to your questions and other questions.
> 
> I am proposing dynamically generating the following aspects 
> of SBVR using
> EClass:
> 
>       object types of type text or quantity as EAttributes of 
> type ESTRING
> or EINT
> 
>       characteristics -- as EAttribute of type EBOOLEAN
> 
>       other object types -- as EClass
> 
>       binary fact types -- as EReference or EList
> 
> I also want to look into implementing n-ary fact types and 
> objectifications
> as extensions of EReference / EList because that would fit 
> better with the
> above.  I propose that all other SBVR concepts would be 
> implemented in the
> "conventional" way.
> 
> The EMF book (2nd edition, section 14.3) says that "All 
> EObjects, whether
> generated, dynamic, or these generated/dynamic hybrids, 
> support exactly the
> same reflective APIs. So, they can be freely mixed and used with all
> reflection-based generic EMF utilities and frameworks, including the
> persistence framework, change recorders, the validation framework, and
> EMF.Edit. The persistence framework also supports dynamic EMF 
> directly by
> automatically demand-loading serialized models to provide 
> needed dynamic
> implementations for arbitrary instances. "
> 
> The text above is not clear (to me, at least) about whether "all
> reflection-based generic EMF utilities and frameworks" work 
> at both the
> modeling level and the instance level.  Since I am proposing 
> to represent
> an SBVR vocabulary with a combination of dynamically-generated and
> statically-generated EMF components, and the vocabulary needs both
> model-level and instance-level elements, I definitely need to 
> clarify these
> questions.   Part of that can be figuring out whether one can export a
> regular .ecore model file for dynamically-generated EMF components.
> 
> --------------------------------
> 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-bounces@xxxxxxxxxxx wrote on 05/21/2008 03:52:10 PM:
> 
> > Mark,
> >
> > Thanks for taking the time to work on the metamodel design. 
>  I will study
> > your diagrams in more detail to better understand the 
> design rules for
> when
> > a dynamically generated EClass is used, and the trade-offs 
> associated
> with
> > this approach.  I am reluctant to deviate too far from the 
> "conventional
> > approach" to EMF modeling, because this may also limit the 
> use of other
> > related EMF technologies and tools.  For example, how would 
> this impact
> the
> > use of generated Edit providers used to adapt and present SBVR model
> > objects?  How would it impact use of EMFT compare and 
> search tools on
> these
> > models?  And use of M2M transformation tools?
> >
> > I am looking for a well-defined design rule for which parts 
> of an SBVR
> > vocabulary are represented using dynamic EClass instances.  
> If this were
> > separated cleanly as concepts vs. individuals (e.g. Driver 
> vs. Bill),
> then
> > we might consider using a somewhat conventional EMF approach of
> generating a
> > static Ecore model and using it to create/model the 
> individuals.  For
> > example, I believe the EODM project has code to export 
> ontology classes
> to
> > and Ecore model.  That model is then instantiated to 
> represent instances
> of
> > the ontology classes.
> >
> > It would help to understand your proposal if an Ecore model can be
> exported
> > and used to generate EMF model/edit/editor plugins, so that 
> an example
> > EU-Rent model can be created.
> >
> > I will try to get an updated SBVR tools metamodel 
> (refinement of the one
> I
> > started) posted to the bugzilla by end of this week.  I 
> will also post an
> > updated simple EU-Rent vocabulary created using the EMF 
> editor for this
> > model.
> >
> > Regards,
> >   Dave Carlson
> >
> >
> > _______________________________________________
> > mdt-sbvr.dev mailing list
> > mdt-sbvr.dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/mdt-sbvr.dev
> 
> _______________________________________________
> mdt-sbvr.dev mailing list
> mdt-sbvr.dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mdt-sbvr.dev
>