Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [mdt-sbvr.dev] A proposal for modeling Concepts and related 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



Back to the top