RE: [mdt-sbvr.dev] Draft of UML model for tooling metamodel

["Dave Carlson" <dcarlson@xxxxxxxxxxxxxxx>]

Mark,
Thanks for your review and comments.  When I posted the note about these
models, I said that this was *primarily* for review of the strategy for
separating the model into separate .genmodel definitions and therefore into
separate plugins for SBVR compliance points.  The classes in these models is
very preliminary and only intended as a quick first prototype to test the
model modularization.

I will review and reply to your other points in a separate message.  But one
quick observation: EMF is aligned with EMOF, not with CMOF, so Association
names in the model are always ignored by EMF.  That's why I omitted them
from the model.  The only thing that matters to EMF is the property end
names of navigable associations.

As for the association end names, we need a consistent strategy for how to
name these property ends so that a useful model API is generated.  We can
require that all property end names are equal to the SBVR spec metamodel
(omitting the association name), but those name often create an awkward API.
Again, I was only exploring these ideas in the prototype model to initiate
discussions like this one.

Dave

> -----Original Message-----
> From: mdt-sbvr.dev-bounces@xxxxxxxxxxx 
> [mailto:mdt-sbvr.dev-bounces@xxxxxxxxxxx] On Behalf Of Mark H Linehan
> Sent: Monday, May 12, 2008 10:55 AM
> To: SBVR developer list
> Subject: Re: [mdt-sbvr.dev] Draft of UML model for tooling metamodel
> 
> 
> Specific omments on the initial SBVR vocabulary that Dave 
> posted on May 2:
> 
> * SBVR.dl2 has classes "Package" and  "Model" that don't 
> appear in the SBVR specification.  Why do we need these?
> * SBVR-LFSV.dl2: the association between 
> ClosedSemanticFormulation and Meaning has a name "formulates" 
> on the "Meaning" end.  This is wrong.  The name of the 
> association itself should be "formulates" or "closed semantic 
> formulation formulates meaning".
> * SBVR-MRV.dl2, About Concepts view: A FactType has a Role, 
> not a FactTypeRole.  (SBVR Figure 8.2 seems to have an error 
> where it shows "fact type role is in fact type".  There is no 
> such fact type.)
> * SBVR-MRV.dl2, Package view: Element, PackagableElement, 
> Package are not part of SBVR.  A ConceptualSchema does not 
> own Representations.
> * SBVR-MRV.dl2, Meanings view: ConceptType is not in SBVR
> * SBVR-VDBV.dl2, Symbolization view: QualifiedDesignations is 
> not in SBVR. Would it make sense to eliminate it and moved 
> preferred/prohibited booleans up to Designation itself?
> * SBVR-VDBV.dl2, Vocabularies view: in most cases, 
> association names are used incorrectly as association end names
> 
> General comments:
> 
> * We need to decide the top-level container for SBVR.  A 
> terminological dictionary?  A vocabulary?  Body of shared 
> meanings/shared concepts?  A community?  How do these relate 
> to conceptual schema and fact model?
> * We should avoid adding new classes and associations, etc.  
> When we do, we should include notes explaining what they mean.
>  * Associations should be named according to the diagrams and 
> associated fact types, when the relationship is other than 
> "has".  For example, "Conceptual Schema includes Concept".
> 
> --------------------------------
> 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
> 
>