[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [mdt-sbvr.dev] Draft of UML model for tooling metamodel
|
Yes, when I reread one of your other notes, I saw that you're not really
looking for detail comments. Sorry to take your time on those, then.
Rereading some of Stan's email -- I agree with him that we should use
"fact model" as the top-level container. This thinking is consistent with
SBVR's "fact orientation". Then an SBVR file is a fact model that owns a
set of facts which fit the various SBVR conceptual models. Such a file
may include one or more terminological dictionaries, bodies of shared
meanings, etc. We can treat those as views over the facts -- groupings of
the facts that are useful for various purposes or user sets.
Regarding association names -- these are useful in the model for
identification purposes, even if they don't get carried over into the EMF
model.
Regarding association end names -- here's a strategy:
case 1) When the SBVR figure shows an association end name use that.
case 2) Otherwise, use the preferred name of the concept at that end
of the association.
How does case 2 generate an awkward API?
--------------------------------
Mark H. Linehan
STSM, Model Driven Business Transformation
IBM Research
phone: (914) 945-1038 or IBM tieline 862-1038
internet: mlinehan@xxxxxxxxxx
"Dave Carlson"
<dcarlson@xmlmode
ling.com> To
Sent by: "'SBVR developer list'"
mdt-sbvr.dev-boun <mdt-sbvr.dev@xxxxxxxxxxx>
ces@xxxxxxxxxxx cc
Subject
05/12/2008 01:06 RE: [mdt-sbvr.dev] Draft of UML
PM model for tooling metamodel
Please respond to
SBVR developer
list
<mdt-sbvr.dev@ecl
ipse.org>
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
>
>
_______________________________________________
mdt-sbvr.dev mailing list
mdt-sbvr.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-sbvr.dev
