[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [mdt-sbvr.dev] A proposal for modeling Concepts andrelated aspects
|
Stan,
I've never tried to define individual concepts in UML and then use the
UML-->EMF path to convert them to EMF. I don't know (and doubt whether)
that works.
Of course, dynamically creating individual concepts in Java code is easy.
--------------------------------
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@hendryxasso
c.com> To
Sent by: "'SBVR developer list'"
mdt-sbvr.dev-boun <mdt-sbvr.dev@xxxxxxxxxxx>
ces@xxxxxxxxxxx cc
Subject
05/23/2008 01:00 RE: [mdt-sbvr.dev] A proposal for
PM modeling Concepts andrelated
aspects
Please respond to
SBVR developer
list
<mdt-sbvr.dev@ecl
ipse.org>
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
>
_______________________________________________
mdt-sbvr.dev mailing list
mdt-sbvr.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-sbvr.dev
