Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [mdt-sbvr.dev] Packaging convention

Anders,
Thanks for taking a look at this.

> 
> Is it correct to assume that currently the Top level container is 
> Package, that is hierarchal (nestable)?
> If so then what are the concrete tooling relation(s) to Set?
> If so what are the idea about relations to specific subs of Set, i.e. 
> Bodyofsharedmeaning, Vocabulary etc.?

First, in the SBVR spec metamodel, *none* of the associations are
composition, so none of the model elements may be a "root" for a
hierarchically nested model file.  I tried to use Set for this, but chaning
the Set::elements property to composition would not satisfy other uses where
Set refers to other model elements, but does not own them.
BodyOfSharedMeanings and Vocabulary also refer to elements but do not own
them.

So I created Package only for use in the tooling metamodel to be this
top-level root that can own, by composition, any Thing in the model.  I
propose that Package may be nested to assist modelers in organizing
vocabularies and rules in a modular design.  I have a lot of experience in
working with UML modelers, and they always want to use packages to organize
a large model.  I expect the same requirement from SBVR users.

If you look at the sample models attached to my 16 June posting, you'll see
that the nested package structure is flattened (and lost) when transforming
to the SBVR XMI exchange format.  Similarly, importing an XMI exchange file
into the SBVR tooling metamodel would create one Package to represent the
XMI document root.

> 
> Just to test the thinking in the current design, what about 
> creating a 
> specific "Package" that is a single root packaging construct for a 
> tooling file? Maybe named SBVRToolModel or SBVRPackage os 
> similar to get 
> the reading a feeling that the content belongs to the SBVR 
> family of files.

This is exactly what Package represents.  I don't see any need to add a
prefix, e.g. SBVRPackage.  The similar model elements in UML are named Model
and Package, not UMLModel and UMLPackage.

If this project team decides not to support nested Packages in the tooling
model, just remove the recursive association and you will have a single
root.  But please think about end-user use cases and the benefits of
organizing a very large SBVR model.

Regards,
  Dave Carlson



Back to the top