Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
SBVR Compliance Points
Compliance Points
For a complete description of compliance points, see section 2.2 of the SBVR specification.
- Meaning and Representation Vocabulary (MRV)
- Vocabulary for Describing Business Vocabulary (VDBV)
- Vocabulary for Describing Business Rules (VDBR)
- Logical Formulation of Semantics Vocabulary (LFSV)
- SBVR Complete (all of the above)
Strategies for Metamodel Design
There are several possibilities for designing a metamodel that supports these compliance points.
- Create one merged metamodel and one corresponding Eclipse plugin implementation that represents the complete content of full SBVR compliance. This is the approach used by the Eclipse UML2 Project. Tool developers use this complete model implementation and create alternative user interface features for hiding or limiting selection of metamodel elements.
- Create one merged metamodel as in the first stragegy, but also annotate the Ecore model so that each metamodel element includes a reference to which compliance point(s) are supports. This approach is not supported by the current EMF tooling and would require enhancements or local customization for SBVR.
- Create a model for each compliance point and use MOF package import instead of package merge. Create a separate Eclipse plugin implementation for each compliance point model, with Eclipse plugin dependencies corresponding to the MOF package imports. A tool developer may then choose which Eclipse plugin represents (only) the SBVR concepts included and supported in his/her tool.
The third alternative is used in this preliminary design and implementation.
Multiple Plug-in Design
The SBVR specification metamodel indicates use of MOF package merge, which would prohibit use of the third design strategy. However, the specification includes very few package interdependencies that require use of package merge. (Unlike the the UML specification metamodel where package merge is an integral part of the design.) The current SBVR Tools Metamodel design attempts minor refactoring so that MOF package import may be used instead of package merge. If this approach is not successful, or is undesirable by SBVR project team memebers, then we will revert to the first design strategy for the 1.0 release of this project.
The UML and Ecore models for the SBVR Tools Metamodel are checked into CVS in the plugin: org.eclipse.sbvr. No generated code is committed to CVS for this preliminary design, but you can easily generate all plugins from the five .genmodel files. To test the full configuration, generate the Model and Edit plugins for each genmodel, and the Editor plugin for SBVR.genmodel.
Your workspace will contain these plugins:
- org.eclipse.sbvr.mrv
- org.eclipse.sbvr.mrv.edit
- org.eclipse.sbvr.lfsv
- org.eclipse.sbvr.lfsv.edit
- org.eclipse.sbvr.vdbv
- org.eclipse.sbvr.vdbv.edit
- org.eclipse.sbvr.vdbr
- org.eclipse.sbvr.vdbr.edit
- org.eclipse.sbvr.sbvr
- org.eclipse.sbvr.sbvr.edit
- org.eclipse.sbvr.editor
The benefit of this approach is that if an SBVR tool developer wanted to create an editor or transformation tools that supported only the LFSV compliance point, then he/she would require only the org.eclipse.sbvr.mrv and org.eclipse.sbvr.lfsv plugins and no other SBVR concepts would be included or available.
Your comments and feedback are welcome; please send them to the project developer mail list, see SBVR Feedback.