[
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
|
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