Jump to: navigation, search

Difference between revisions of "MDT-SBVR 0.7 Project Plan"

m (SBVR Metamodel Implementation)
m (minor rewording of plan items)
 
(11 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
'''''Note: This is a draft of the requirements document and is expected to change.'''''
 
'''''Note: This is a draft of the requirements document and is expected to change.'''''
  
''Last revised: --{{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}''
+
''Last revised: {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}''
  
 
''Please send your feedback on this draft document to the [mailto:mdt-sbvr.dev@eclipse.org mdt-sbvr.dev@eclipse.org]'' developer mailing list.
 
''Please send your feedback on this draft document to the [mailto:mdt-sbvr.dev@eclipse.org mdt-sbvr.dev@eclipse.org]'' developer mailing list.
Line 7: Line 7:
 
Back to [[MDT-SBVR | SBVR Main Page]]
 
Back to [[MDT-SBVR | SBVR Main Page]]
  
=Overview=
+
This project plan and associated requirements are the result of an open and transparent process and includes input from those who have expressed an interest in the project. That said, the success of the project and its deliverables is soley dependent upon the contributions from its community membership. If you are interested in contributing to the project in the delivery of its stated goals, you are more than welcome!
 +
 
 +
=Requirements=
 +
The requirements consist of plan items for the project; see [[MDT-SBVR_0.7 Release Requirements#Requirements Overview | Requirements Overview]] for a description of how the plan is organized. Each plan item covers a feature or API that is to be added, or some aspect that is to be improved. Each plan item has its own entry in the Eclipse [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&product=MDT&component=SBVR&long_desc_type=allwordssubstr&bug_file_loc_type=allwordssubstr&status_whiteboard_type=allwordssubstr&keywords_type=allwords&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bugidtype=include&cmdtype=doit SBVR bugzilla] database, with a title and a concise summary (usually a single paragraph) that explains the work item at a suitably high enough level so that everyone can readily understand what the work item is without having to understand the nitty-gritty detail.
 +
 
 +
Not all plan items represent the same amount of work; some may be quite large, others, quite small. Although some plan items are for work that is more pressing that others, the plan items appear in no particular order.
 +
 
 +
==SBVR Metamodel Implementation==
 +
'''''Proposed'''''
 +
:* [[Image:help.gif]] '''SBVR test cases'''. Work with the SBVR community to create one or more detailed SBVR test cases stored as XMI files. The test cases should illustrate best practices for organizing and writing vocabularies and rules. ([https://bugs.eclipse.org/bugs/show_bug.cgi?id=226011 bug#226011])
 +
:* '''Enhance model validation'''. Add EMF validation constraints for SBVR structural rules in the specification. ([https://bugs.eclipse.org/bugs/show_bug.cgi?id=226012 bug#226012])
 +
:* '''SBVR 1.1 compliance'''. Modify the metamodel and XMI interoperability as necessary for compliance with SBVR 1.1. ([https://bugs.eclipse.org/bugs/show_bug.cgi?id=226013 bug#226013])
 +
 
 +
'''''Committed'''''
 +
:* '''SBVR exchange document metamodel'''. Implement the CMOF metamodel delivered with the SBVR 1.0 specification. This metamodel will be used for XMI serialization to the SBVR Exchange Document format. Fix metamodel bugs and provide feedback to the SBVR RTF, as required. ([https://bugs.eclipse.org/bugs/show_bug.cgi?id=226006 bug#226006])
 +
:* '''SBVR metamodel for tool developers'''. Design an SBVR metamodel that is optimized for tool development and that enforces structural constraints in the specification. ([https://bugs.eclipse.org/bugs/show_bug.cgi?id=226010 bug#226010])
 +
:* '''Load and Save XMI compliant with SBVR 1.0'''. Provide a resource handler or transformation that enables SBVR models to be loaded from and saved to SBVR exchange document XMI files that are compliant with the SBVR 1.0 specification. ([https://bugs.eclipse.org/bugs/show_bug.cgi?id=226008 bug#226008])
 +
 
 +
'''''Deferred'''''
 +
:*
 +
 
 +
==SBVR Sample Tools==
 +
'''''Proposed'''''
 +
:* '''Project Explorer navigator view'''. Provide an o.e.sbvr.ui.navigator plug-in that contributes a Project Explorer content provider, support for undo/redo, edit menus, SaveablesProvider, content filtering, and virtual content folders. ([https://bugs.eclipse.org/bugs/show_bug.cgi?id=226018 bug#226018])
 +
:* '''Import business vocabulary from UML'''. Work with the SBVR community to define and implement transformation from UML domain models to SBVR vocabulary. ([https://bugs.eclipse.org/bugs/show_bug.cgi?id=226019 bug#226019])
 +
:* [[Image:help.gif]] '''Transform SBVR to Platform-Independent Models (PIM)'''. For example, to support IT design and implementaiton using UML and OCL, production rule engines, etc. ([https://bugs.eclipse.org/bugs/show_bug.cgi?id=226021 bug#226021])
 +
 
 +
'''''Committed'''''
 +
:* '''Menus for adding new concepts'''. Implement popup menu actions contributed to sample editor and Project Explorer view, e.g. Add Term, Add Definition, etc. Each action will add and link all required metamodel elements: Concept, Designation, and signifier Expression.([https://bugs.eclipse.org/bugs/show_bug.cgi?id=226017 bug#226017])
 +
 
 +
'''''Deferred'''''
 +
:*
 +
 
 +
=Requirements Overview=
 
===Status of a requirement===
 
===Status of a requirement===
The current status of a requirement can be one of the following categories.
+
Plan items reflect new features in this project, or areas where existing features will be significantly reworked. Plan items are indicated using the [Plan Item] keyword and have a state determined by 'Assigned To' and 'Target Milestone' fields in Bugzilla. Below is a list of possible states and what they mean:
 
    
 
    
 
'''''Proposed'''''  
 
'''''Proposed'''''  
  
These are requirements that are being considered for this release.  These are items that are either being investigated or items that the project would like to explore but are not yet Committed. Most of the requirements should start as proposed items. After a review and some amount of detailed planning, their status will either become committed or deferred.  
+
These are requirements that are being considered for this release.  These are items that are either being investigated or items that the project would like to explore but are not yet Committed. Most of the requirements should start as proposed items. After a review and some amount of detailed planning, their status will either become committed or deferred. Bugzillas without an assigned developer are proposed, but not committed for a particular release.
 
    
 
    
 
'''''Committed'''''  
 
'''''Committed'''''  
  
These are requirements that the project team is definitely going to address in the release. Resources and some amount of detailed plans have been identified for such items.
+
These are requirements that the project team is definitely going to address in the release. Resources and some amount of detailed plans have been identified for such items. Bugzillas with a target milestone and developer assigned are considered committed in that release.
 
    
 
    
 
'''''Deferred'''''  
 
'''''Deferred'''''  
  
These are valid requirements that started in a Proposed state but will not be addressed in this release. Each such item will have a brief note explaining the cause for the deferral.
+
These are valid requirements that started in a Proposed state but will not be addressed in this release. Each such item will have a brief note explaining the cause for the deferral. Bugzillas with an unspecified target milestone are deferred, and not scheduled for the current release.
  
 
===Flags on a requirement===
 
===Flags on a requirement===
Line 33: Line 66:
  
 
This flag is used to mark items as they are mostly finished. While the items might continue to have bugs fixed etc. until the final release, we expect each milestone will have some items to mark as "complete", such as those going into a New and Noteworthy document for that milestone. This flag is a good indication that something is ready to be fully tested, documented, etc.
 
This flag is used to mark items as they are mostly finished. While the items might continue to have bugs fixed etc. until the final release, we expect each milestone will have some items to mark as "complete", such as those going into a New and Noteworthy document for that milestone. This flag is a good indication that something is ready to be fully tested, documented, etc.
 
=Requirements=
 
 
==SBVR Metamodel Implementation==
 
'''''Proposed'''''
 
* '''Enhance metamodel for tool developers'''. The SBVR metamodel has a very "flat" structure without composition/containment or navigable associations. Modify the metamodel structure as necessary to enable improved APIs for tool development. ([https://bugs.eclipse.org/bugs/show_bug.cgi?id=xxx bug#xxx])
 
* '''Enhance model validation'''. Add EMF validation constraints for SBVR structural rules in the specification. ([https://bugs.eclipse.org/bugs/show_bug.cgi?id=xxx bug#xxx])
 
* '''SBVR 1.1 compliance'''. Modify the metamodel and XMI interoperability as necessary for compliance with SBVR 1.1. ([https://bugs.eclipse.org/bugs/show_bug.cgi?id=xxx bug#xxx])
 
 
'''''Committed'''''
 
* '''EMF plug-ins for SBVR 1.0 CMOF metamodel'''. Generate EMF model, edit, and editor plug-ins using the CMOF model delivered with the SBVR 1.0 specification. Fix metamodel bugs and provide feedback to the SBVR RTF, as required. ([https://bugs.eclipse.org/bugs/show_bug.cgi?id=xxx bug#xxx])
 
* '''Load and Save XMI compliant with SBVR 1.0'''. ([https://bugs.eclipse.org/bugs/show_bug.cgi?id=xxx bug#xxx])
 
 
'''''Deferred'''''
 
 
==SBVR Sample Tools==
 
'''''Proposed'''''
 
* '''Project Explorer navigator view'''. Provide an o.e.sbvr.ui.navigator plug-in that contributes a Project Explorer content provider, support for undo/redo, edit menus, SaveablesProvider, content filtering, and virtual content folders. ([https://bugs.eclipse.org/bugs/show_bug.cgi?id=xxx bug#xxx])
 
* '''Import business vocabulary from UML'''. Work with the SBVR community to define and implement transformation from UML domain models to SBVR vocabulary. ([https://bugs.eclipse.org/bugs/show_bug.cgi?id=xxx bug#xxx])
 
* [[Image:help.gif]] '''Transform SBVR to Platform-Independent Models (PIM)'''. For example, to support IT design and implementaiton using UML and OCL, production rule engines, etc.
 
 
'''''Committed'''''
 
* '''Menus for adding new concepts'''. Implement popup menu actions contributed to sample editor and Project Explorer view, e.g. Add Term, Add Definition, etc. ([https://bugs.eclipse.org/bugs/show_bug.cgi?id=xxx bug#xxx])
 
 
'''''Deferred'''''
 
 
  
 
[[Category:Modeling]]
 
[[Category:Modeling]]
 
[[Category:MDT]]
 
[[Category:MDT]]
 
[[Category:SBVR]]
 
[[Category:SBVR]]

Latest revision as of 17:15, 12 June 2008

Note: This is a draft of the requirements document and is expected to change.

Last revised: 2008-06-12

Please send your feedback on this draft document to the mdt-sbvr.dev@eclipse.org developer mailing list.

Back to SBVR Main Page

This project plan and associated requirements are the result of an open and transparent process and includes input from those who have expressed an interest in the project. That said, the success of the project and its deliverables is soley dependent upon the contributions from its community membership. If you are interested in contributing to the project in the delivery of its stated goals, you are more than welcome!

Requirements

The requirements consist of plan items for the project; see Requirements Overview for a description of how the plan is organized. Each plan item covers a feature or API that is to be added, or some aspect that is to be improved. Each plan item has its own entry in the Eclipse SBVR bugzilla database, with a title and a concise summary (usually a single paragraph) that explains the work item at a suitably high enough level so that everyone can readily understand what the work item is without having to understand the nitty-gritty detail.

Not all plan items represent the same amount of work; some may be quite large, others, quite small. Although some plan items are for work that is more pressing that others, the plan items appear in no particular order.

SBVR Metamodel Implementation

Proposed

  • Help.gif SBVR test cases. Work with the SBVR community to create one or more detailed SBVR test cases stored as XMI files. The test cases should illustrate best practices for organizing and writing vocabularies and rules. (bug#226011)
  • Enhance model validation. Add EMF validation constraints for SBVR structural rules in the specification. (bug#226012)
  • SBVR 1.1 compliance. Modify the metamodel and XMI interoperability as necessary for compliance with SBVR 1.1. (bug#226013)

Committed

  • SBVR exchange document metamodel. Implement the CMOF metamodel delivered with the SBVR 1.0 specification. This metamodel will be used for XMI serialization to the SBVR Exchange Document format. Fix metamodel bugs and provide feedback to the SBVR RTF, as required. (bug#226006)
  • SBVR metamodel for tool developers. Design an SBVR metamodel that is optimized for tool development and that enforces structural constraints in the specification. (bug#226010)
  • Load and Save XMI compliant with SBVR 1.0. Provide a resource handler or transformation that enables SBVR models to be loaded from and saved to SBVR exchange document XMI files that are compliant with the SBVR 1.0 specification. (bug#226008)

Deferred

SBVR Sample Tools

Proposed

  • Project Explorer navigator view. Provide an o.e.sbvr.ui.navigator plug-in that contributes a Project Explorer content provider, support for undo/redo, edit menus, SaveablesProvider, content filtering, and virtual content folders. (bug#226018)
  • Import business vocabulary from UML. Work with the SBVR community to define and implement transformation from UML domain models to SBVR vocabulary. (bug#226019)
  • Help.gif Transform SBVR to Platform-Independent Models (PIM). For example, to support IT design and implementaiton using UML and OCL, production rule engines, etc. (bug#226021)

Committed

  • Menus for adding new concepts. Implement popup menu actions contributed to sample editor and Project Explorer view, e.g. Add Term, Add Definition, etc. Each action will add and link all required metamodel elements: Concept, Designation, and signifier Expression.(bug#226017)

Deferred

Requirements Overview

Status of a requirement

Plan items reflect new features in this project, or areas where existing features will be significantly reworked. Plan items are indicated using the [Plan Item] keyword and have a state determined by 'Assigned To' and 'Target Milestone' fields in Bugzilla. Below is a list of possible states and what they mean:

Proposed

These are requirements that are being considered for this release. These are items that are either being investigated or items that the project would like to explore but are not yet Committed. Most of the requirements should start as proposed items. After a review and some amount of detailed planning, their status will either become committed or deferred. Bugzillas without an assigned developer are proposed, but not committed for a particular release.

Committed

These are requirements that the project team is definitely going to address in the release. Resources and some amount of detailed plans have been identified for such items. Bugzillas with a target milestone and developer assigned are considered committed in that release.

Deferred

These are valid requirements that started in a Proposed state but will not be addressed in this release. Each such item will have a brief note explaining the cause for the deferral. Bugzillas with an unspecified target milestone are deferred, and not scheduled for the current release.

Flags on a requirement

A requirement can have these additional flags.

Help Wanted Help.gif

These are valid requirements in the 'Propsed' or 'Deferred' status that require volunteers to work on them. These are especially good candidates for companies or individuals who want to get involved with SBVR in a large way.

Complete File:Checkmark-10x10.gif

This flag is used to mark items as they are mostly finished. While the items might continue to have bugs fixed etc. until the final release, we expect each milestone will have some items to mark as "complete", such as those going into a New and Noteworthy document for that milestone. This flag is a good indication that something is ready to be fully tested, documented, etc.