Skip to main content
Jump to: navigation, search

Capella/Tutorials/Extensibility/Validation Rules

Validation Rules

Model Validation Rules

Capella offers a model validation functionality. This validation is available through a contextual menu command that executes a set of rules on the selected model element.

The set of executed rules can be customized through the preferences (non-mandatory rules can be activated or deactivated), and additional specific rules can be contributed through an extension point.

Extension Point Description

An Eclipse extension point allows plug-ins to contribute constraints into the EMF model validation framework.

The extension point is provided by:

  • the plug-in org.eclipse.emf.validation
  • and its identifier constraintProviders.

Following figures details the contents of the extension point:

Capella ValidationRules ExtensionPoint

The contribution to the extension point is done in the plugin.xml file of the plugin. Open this file and focus on the plugin.xml tab:

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.2"?>
<plugin>
   <extension point="org.eclipse.emf.validation.constraintProviders">
      <constraintProvider>
         <package namespaceUri=""/>
         <constraints categories="">
            <constraint
                  class=""
                  id=" "
                  isEnabledByDefault="true"
                  lang="Java"
                  mode="Batch"
                  name=" "
                  severity="ERROR"
                  statusCode="1">
               <message>
               </message>
               <target class=""/>
               <description>
               </description>
            </constraint>
         </constraints>
      </constraintProvider>
   </extension>
</plugin>


Detail of the different fields
namespaceUri Namespace URI of an EMF package supported by the constraint provider. Following is the list of all URI currently available in Capella. Each one matches a subset of the Capella Metamodel:
Capella Modeller	http://www.polarsys.org/capella/core/modeller/1.1.0
Capella Core		http://www.polarsys.org/capella/core/core/1.1.0
Capella Common		http://www.polarsys.org/capella/core/common/1.1.0
Composite Structure	http://www.polarsys.org/capella/core/cs/1.1.0
Operational Analysis	http://www.polarsys.org/capella/core/oa/1.1.0
System Analysis	        http://www.polarsys.org/capella/core/ctx/1.1.0
Logical Architecture	http://www.polarsys.org/capella/core/la/1.1.0
Physical Architecture	http://www.polarsys.org/capella/core/pa/1.1.0
Deployment		http://www.polarsys.org/capella/core/pa/deployment/1.1.0
EPBS			http://www.polarsys.org/capella/core/epbs/1.1.0
Functional Analysis	http://www.polarsys.org/capella/core/fa/1.1.0
Shared Model		http://www.polarsys.org/capella/core/sharedmodel/1.1.0
Requirement		http://www.polarsys.org/capella/core/requirement/1.1.0
Interaction		http://www.polarsys.org/capella/core/interaction/1.1.0
Information		http://www.polarsys.org/capella/core/information/1.1.0
Communication		http://www.polarsys.org/capella/core/information/communication/1.1.0
Data Type		http://www.polarsys.org/capella/core/information/datatype/1.1.0
Data Value		http://www.polarsys.org/capella/core/information/datavalue/1.1.0

Modelling Core		http://www.polarsys.org/capella/common/core/1.1.0
Behavior		http://www.polarsys.org/capella/common/behavior/1.1.0
Activity		http://www.polarsys.org/capella/common/activity/1.1.0

Note: The meta-models URI has changed: only the version number as it used to change between a version N and N+1:

http://www.polarsys.org/capella/common/.../1.0.0
-> http://www.polarsys.org/capella/common/.../1.1.0
http://www.polarsys.org/capella/core/.../1.0.0
-> http://www.polarsys.org/capella/core/.../1.1.0
<constraints categories="">
   <constraint
Container for constraint declarations. The constraints grouped in one of these elements belong to the same set of categories.
  • categories - A comma-delimited list of fully-qualified category IDs to which the constraints grouped in this element belong. If none are specified, then the constraints are members of the default category. It is not recommended, however, to use the default category. Note that it is not a good idea to include constraints simultaneously in a category and some ancestor or descendent category. This would be quite confusing to the user.

Here is the list of all categories currently available in Capella. New ones can be created but the root prefix shall always be capella.category:

capella.category/quality
capella.category/integrity
capella.category/design
capella.category/design/coverage
capella.category/design/well-formedness
capella.category/design/well-formedness/state_machines
capella.category/design/well-formedness/dataflows
capella.category/design/well-formedness/components
capella.category/design/well-formedness/data
capella.category/design/well-formedness/interfaces
capella.category/design/well-formedness/scenarios
capella.category/design/well-formedness/capabilities
capella.category/design/well-formedness/use_cases
capella.category/design/consistency
capella.category/design/completeness
capella.category/structural_conformance_to_m2
capella.category/transition
capella.category/transition/consistency
capella.category/transition/consistency/data
capella.category/transition/consistency/state_machines
capella.category/transition/consistency/interfaces
capella.category/transition/consistency/dataflows
capella.category/transition/consistency/scenarios
capella.category/transition/consistency/capabilities
capella.category/transition/justification
capella.category/transition/justification/physical_architecture
capella.category/transition/justification/logical_architecture
capella.category/transition/justification/epbs
capella.category/transition/justification/generic
capella.category/transition/justification/system_analysis

Note: categories are <capella_source_code_tree>\core\plugins\org.polarsys.capella.core.validation\plugin.xml
Modify this file to add new categories (they must be children of capella.category)

<constraint
      class=""
      id=" "
      isEnabledByDefault="true"
      lang="Java"
      mode="Batch"
      name=" "
      severity="ERROR"
      statusCode="1">
   <message>
   </message>
   <target class=""/>
   <description>
   </description>
</constraint>
Defines a single constraint:
  • id - A unique identifier for the constraint.
  • name - A localizable name for the constraint (appears in the GUI). Note that {0} identify the element type and {1} its name.
  • lang - Identifies the language in which the constraint is expressed. The language is not case-sensitive. The currently supported languages are Java and OCL. For the Java language, this element identifies a class that extends the AbstractValidationRule class. Other languages, such as OCL, may make use of the body of the constraint element and/or one or more parameters.
  • severity - The severity of the problem if the constraint is violated. This correlates to the severity of tasks in the Tasks view of the Eclipse environment. The default severity (if none specified) is ERROR. The CANCEL severity should be used with caution, as it causes the validation operation to be interrupted, possibly resulting in the loss of valuable diagnostic information from other constraints.
  • statusCode - The plug-in unique status code, useful for logging.
  • class - For "Java" language constraints only, identifies a class implementing the constraint. The class must extend the AbstractValidationRule class, providing an implementation of the abstract method:
    validate()
  • mode - Describes whether a constraint operates in batch mode, live mode, or feature mode. The default is batch if not specified.
  • isEnabledByDefault - Indicates if this constraint should be enabled by default. User can change this setting in preferences. The default value is true.

Validation Rule Implementation

The AbstractValidationRule class that is extended by CapellaTutorialValidationRule class provides some facilities to manage messages.

Notes:

  • To return a valid status, return the result of the call to the method:
    createSuccessStatus()
  • To return an invalid status, return the result of the call to the method:
    createFailureStatus(...)
    The parameters are the validation context and a set of parameters that will be passed to your message (they will be used only if you defined {0}, {1}, etc. parameters in your message text: see the previous section).

Sample Validation Rule

In this sample validation rule, we check that all Functions in Physical Architecture have a description and a summary.

First, we create a new plugin project using Capella Studio.

Then, we edit the MANIFEST/MANIFEST.MF file to add:

  • the necessary dependencies in the Dependencies tab:
    • org.eclipse.emf.validation
    • org.polarsys.capella.core.validation
  • and the contribution to the extension point:

Select the Extensions tab then click on the add... button. The plugin.xml file is generated. Open this file and select the plugin.xml tab:

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.2"?>
<plugin>
   <extension point="org.eclipse.emf.validation.constraintProviders">
      <constraintProvider>
         <package namespaceUri="http://www.polarsys.org/capella/core/pa/1.1.0"/>
         <constraints categories="capella.category/design/well-formedness/data">
            <constraint
                  class="myfirstvalidationrule.CapellaTutorialValidationRule"
                  id="DWF_PA_99"
                  isEnabledByDefault="true"
                  lang="Java"
                  mode="Batch"
                  name="DWF_PA_99 - Physical Architecture Functions Description and Summary"
                  severity="ERROR"
                  statusCode="1">
               <message>
                  The function {1} has either no description or no summary!
               </message>
               <target class="PhysicalFunction"/>
               <description>
                  This validation rule checks that all Functions in Physical Architecture have a description and a summary.
               </description>
            </constraint>
         </constraints>
      </constraintProvider>
   </extension>
</plugin>


Then we implement the code of the validation rule:


package myfirstvalidationrule;
import org.eclipse.core.runtime.IStatus;
import org.eclipse.emf.ecore.EObject;
import org.eclipse.emf.validation.IValidationContext;
import org.polarsys.capella.common.data.modellingcore.AbstractNamedElement;
import org.polarsys.capella.core.data.pa.PhysicalFunction;
import org.polarsys.capella.core.validation.rule.AbstractValidationRule;

public class CapellaTutorialValidationRule extends AbstractValidationRule {
  /**
   * {@inheritDoc}
   */
  @Override
  public IStatus validate(IValidationContext ctx) {
    EObject eObj = ctx.getTarget();
    if (eObj instanceof PhysicalFunction) {
      PhysicalFunction capellaElt = (PhysicalFunction) eObj;
      String desc = capellaElt.getDescription();
      String summary = capellaElt.getSummary();
      if (desc == null || desc.isEmpty() || summary == null || summary.isEmpty()) {
        if (capellaElt instanceof AbstractNamedElement) {
          AbstractNamedElement namedElt = (AbstractNamedElement) capellaElt;
          return ctx.createFailureStatus(new Object[] {capellaElt.eClass().getName(), namedElt.getName()});
        }
        return ctx.createFailureStatus(new Object[] {capellaElt.eClass().getName(), "<unnamed>"});
      }
    }
    return ctx.createSuccessStatus();
  }
}


Note: A dependency to org.polarsys.capella.core.validation plugin shall be added.



Now we can export the plugin using right-click on the project directory > Export > Plug-in Development > Deployable plug-ins and fragments.

Select Archive file radio button and give the archive a name (e.g. <SOME_PATH>/MyValidationRule.zip) and click on finish.

Extract the contents of the generated archive into <CAPELLA_HOME_DIRECTORY>/eclipse/dropins directory and launch Capella.

Open Windows > Preferences in the menu bar, expand Model Validation and select Constraints.

Expand Capella > Design > Well-formedness and click on Data.

Scroll down and check the validation rule is present. Click on it to visualize its description.

Capella ValidationRules SamplePrefs


Click on cancel and create a Capella project, and a Physical Function at Physical Architecture level.

Right-click on this function and select Validate. Check that an error is raised, meaning the sample validation rule has been called:

Capella ValidationRules SampleError


This tutorial will be enriched to address other topics like contributing to the quick fix, etc.

You can download the sample validation rule source code following File:Capella sample validation rule.zip.

Back to the top