Doc
eMDE is a component with a top-level metamodel which enables to support metamodel extensions by aggregation. This component is essentially used for viewpoint development.
The eMDE API has an EMF-based API deduced from the following metamodel.
eMDE is a reduced component but structuring for depending components. Indeed, for introduction of the “extension by aggregation” capability, the extensible metaclasses have to inherit from the ExtensibleElement metaclass. Then, when the eMDE metamodel evolves, impacts must be measured for all the metamodels depending on eMDE.
eMDE offers an extension mechanism and the metamodel can be considered itself as an extension point. Aggregating metaclasses inherit from the ElementExtension metaclass. From the extended metaclasses (i.e., ExtensibleElement metaclasses) side, aggregated values are accessible via the “ownedExtensions” reference.
Resource enables to retrieve a resource in the Eclipse platform / workspace, such as a document or model. During the search, it manages the workspace / platform priority. After being marked, a resource can be retrieve by criteria:
- An identifier
- a name
- a domain
- a version
- a set of tags
This class provide API to retrieve programmatically a resource.
Provided by bundle: org.polarsys.kitalpha.resourcereuse
File name: org.polarsys.kitalpha.resourcereuse.helper.ResourceHelper.java
To contribute a resource is done through extension point org.polarsys.kitalpha.resourcereuse.resources
Attributes of the ResourceReuse extension point:
-
id: The ID of the resource (mandatory) -
name: The Name of the resource (mandatory) -
path: Path to access the resource -
version: a version associated to the resource -
domain: The resource domain -
tags: A set of tags separated by a comma
This project suggests doing to create code generation software, which will be extensible by the user easily. This software offers the bellow possibilities:
- to generate several languages (IDL, JAVA, C++, XML, etc.) ;
- to extend the templates code generator;
- to add other generation modules;
- to use several code generators;
- to define code generation strategies.
The generation can be launched:
- Through UI
- Through CommandLine
- Through Code
Four concepts are introduced in this project:
-
Allocation metamodel: may be compared to a generation plan, it defines generation properties and refers to the semantic metamodel; -
Strategy: a Strategy is an algorithm that produces an “Allocation model” from "One model / a set of Model Elements. Given a model or a set of elements, the allocation returns a “Root”, containing a set of “Files” referencing a set of “Types”. You can have multiple strategies for the same Allocations: they will represent different ways to organize the code in the files. You’ll select the one that fits to your need and configure it -
Refinery: Now that the one Strategy has produced the Allocation, we need to refine it. Refining the allocation is actually the process to Reorder elements in one file, add forward declarations, Identify the need to add “imports” or #includes. The refinery is here to satisfy all the constraints given by the strategy. You can have multiple strategies, but you’ll have only one refiner generated language. The Refinery receives an Allocation, and it has to process and enrich it with all sort of details. Once the Refinery has done it’s job, all the complex job has been done and we can apply all our generation pattenrs.The generation code is now very simple, no logic inside !You don’t have any more to care about elements order, imports, etc.. Everything has already been decided. -
Generators: Now that all the complex job has been done, we can delegate the generation to any technology : EGF, Acceleo, StringTemplate, Jet , Java ... The contract here is simply to do what has been written in the Allocation
Composer provides some Services allowing to call/manipulate it.
This metamodel is a generic metamodel, which defines the common concepts for all allocation metamodels. It defines several classes as Root, File and Type. Type refers to a semantic element, i.e. from the semantic model. An allocation metamodel can be compared to a generation plan. It defines the concept of file. a file has a name and a path and contains types. Each type refers to an element of the semantic model. An allocation metamodel may be extended with several concepts. This separation of concerns allows the developer to make very simple generation scripts without concern about complicated computation and complicated model browsing.
Provided by bundle:org.polarsys.kitalpha.composer.metamodel.allocation.base.model
File name: org.polarsys.kitalpha.composer.metamodel.allocation.base.*
This class allows launching programmatically a complete code generation.
Provided by bundle:org.polarsys.kitalpha.composer.core
File name: org.polarsys.kitalpha.composer.api.CodeManagerLauncher.java
This class allows getting Strategies, Refineries and Generators contributing at the Manager extensions points.
Provided by bundle:org.polarsys.kitalpha.composer.core
File name: org.polarsys.kitalpha.composer.api.CodeManagerRegistry.java
Composer is an Eclipse plug-in that defined four extension points:
- Bindings extension point: permits to bind a semantic metamodel to an allocation metamodel.
- Strategy extension point: permits to create an allocation model from a semantic model.
- Refinery extension point: permits to refine an allocation model with additional informations. a refinery is specific to an allocation metamodel. The refinery does the clever work.
- Generators extension point: permits to contribute an entry point for a code generator in order to know itself from the code generator manager.
Define a new EMF metamodel by inheriting the allocation metamodel one, and register it on the given extension point.
Provided by bundle:org.polarsys.kitalpha.composer.core
Extension point name: org.polarsys.kitalpha.composer.allocation.binding.
Contributing a binding to Composer is done through the following extension (in the bundle plugin.xml file):
<extension
point="org.polarsys.kitalpha.composer.allocation.binding">
<binding
Id="org.polarsys.kitalpha.composer.basic.allocation"
Name="A Basic Allocation Metamodel"
NsUri="http://my.allocation.metamodel.ns.uri"
Description="Description body text" >
<businessMetamodelNsUriDeclaration
NsUri="http://metamodel.business.ns.uri">
</businessMetamodelNsUriDeclaration>
<businessMetamodelNsUriDeclaration
NsUri="http://another.metamodel.business.ns.uri">
</businessMetamodelNsUriDeclaration>
</binding>
</extension>
Binding Declaration Attributes:
-
id: The unique ID for the binding (mandatory) -
name: The Name of the Workflow (mandatory) -
description: A quick description for users (optional) -
nsUri: The namespace URI of the allocation metamodel
Business Metamodel Declaration Attributes:
-
nsUriThe namespace URI of the business metamodel (mandatory)
The strategy will allows to create an allocation model from a semantic model
Provided by bundle:org.polarsys.kitalpha.composer.core
Extension point name: org.polarsys.kitalpha.composer.allocation.strategies.
Contributing a strategy to Composer is done through the following extension (in the bundle plugin.xml file):
<extension
point="org.polarsys.kitalpha.composer.allocation.strategies">
<strategy
Class="org.polarsys.kitalpha.composer.example.MyStrategy"
Id="org.polarsys.kitalpha.composer.example.strategy"
Name="A simple Strategy"
NsUri="http://my.allocation.metamodel.ns.uri">
</strategy>
</extension>
Strategy Declaration Attributes:
-
id: The ID of the Strategy. (mandatory) -
name: The Name of the strategy. (mandatory) -
description: A quick description for users. -
nsUri: The namespace URI of the allocation metamodel where the strategy is applicable on. -
class: A class that respects the contract of IStrategy. This class knows how to create an allocation model from a semantic model.
This interface specifies the contract for providing allocation strategy.
Provided by bundle:org.polarsys.kitalpha.composer.core
File name: org.polarsys.kitalpha.composer.extension.points.IStrategy.java
Provided by bundle:org.polarsys.kitalpha.composer.core
Extension point name: org.polarsys.kitalpha.composer.allocation.refineries.
Contributing a refinery to Composer is done through the following extension (in the bundle plugin.xml file):
<extension
point="org.polarsys.kitalpha.composer.allocation.refineries">
<refinery
Class="org.polarsys.kitalpha.composer.example.MyRefinery"
Id="org.polarsys.kitalpha.composer.example.refinery"
Name="A simple Refinery"
NsUri="http://my.allocation.metamodel.ns.uri">
</refinery>
</extension>
Refinery Declaration Attributes:
-
id: The ID of the Refinery. (mandatory) -
name: The Name of the Refinery. (mandatory) -
description: A quick description for users. -
nsUri: The namespace URI of the allocation metamodel where the refinery is applicable on. -
class: A class that respects the contract of IRefinery. This class knows how to refine the allocation model with complex browsing on the business model.
This interface specifies the contract for providing allocation refinery. Provided by bundle:org.polarsys.kitalpha.composer.core File name: org.polarsys.kitalpha.composer. extension.points.IRefinery.java
Provided by bundle:org.polarsys.kitalpha.composer.core
Extension point name: org.polarsys.kitalpha.composer.cots.generators.
Contributing a generator to composer is done through the following extension (in the bundle plugin.xml file):
<extension
point="org.polarsys.kitalpha.composer.cots.generators">
<generator
Class="org.polarsys.kitalpha.composer.cots.example.MyEntryPointGen"
Id="org.polarsys.kitalpha.composer.example.generator"
Name="A simple Generator"
NsUri="http://my.allocation.metamodel.ns.uri">
</generator>
</extension>
Generator Declaration Attributes:
-
id: The ID of the Generator (mandatory) -
name: The Name of the Generator (mandatory) -
description: A quick description for users. -
nsUri: The namespace URI of the allocation metamodel where the Generator is applicable on. (mandatory) -
class: A class that respects the contract of IGenerator. This class call the generation program (scripts, java code …). (mandatory)
This interface specifies the contract for providing a generator entry point. Provided by bundle:org.polarsys.kitalpha.composer.core File name: org.polarsys.kitalpha.composer.extension.points.IGenerator.java
This project defines a generic and agnostic rule application tool. It is designed to be able to discover, infer and schedule application of provided rules. It can do model transformation, when applying transformation rules, other purposes may be impact analysis or model validation. Mostly, transposer is useful where the application is a set of tasks to be done
You will categorize tasks
A 'rule' for each category of tasks
- Yellow rule will perform tasks T0, T5, T6
- Green rule will perform tasks T1, T9, T10
- Orange will perform tasks T2, T3
- Red will perform tasks T7, T8, T4
Define tasks dependencies (or 'premices')
And Transposer will find a way to perform all tasks according to dependencies Task T6 will be the first to be performed (no dependency to others tasks) After, T10, T4, ….. After ?
When tasks have cycle dependencies, it will determine an order to be performed first ?
- Between T8, T9, T3, T2
- Between T3, T4, T5
There is 2 mechanisms for cycle resolution, « Critical dependencies » vs « dependencies », as some dependencies can be considered as “more critical” than others
To make it work, it is possible to define two rules for a task, one Complete and one for Incomplete
- T3, T9, T8, T2 will be performed as incomplete
- Then, T3, T9, T8 and T2 will be performed as complete
The triggered order of tasks can be order can be
- T6, T10 complete only (no cycle, no problem)
- T3, T9, T8, T2, T1, T5, T4, T7, incomplete
- T3, T9, T8, T2, T1, T5, T4, T7 complete
- T0 complete
Transposer provides some Services allowing to call/manipulate it.
This class allows launching programmatically a complete transposer's process.
Provided by bundle: org.polarsys.kitalpha.transposer.core
File name: org.polarsys.kitalpha.transposer.api.TransposerLauncher.java
This class define cadence activities used for each Transposer Workflow Elements.
Provided by bundle: org.polrsys.kitalpha.transposer.core
File name: org.polarsys.kitalpha.transposer.api.TransposerConfiguration.java
Transposer is an Eclipse plug-in that defined one extension point:
- Declares mapping: to define a new mapping for transformation which holds the mappings between rules and their meta classes of the inputted model.
- Bindings extension point: permits to bind a semantic metamodel to an allocation metamodel.
- Strategy extension point: permits to create an allocation model from a semantic model.
- Refinery extension point: permits to refine an allocation model with additional information. a refinery is specific to an allocation metamodel. The refinery does the clever work.
- Generators extension point: permits to contribute an entry point for a code generator in order to know itself from the code generator manager.
Transposer uses Cadence to manage external activities. Four workflow elements are declared:
- Pre Analysis,
- Pre Scheduling,
- Pre Execution,
- Post Execution.
Transposer Core declares the workflows and asks Cadence to run user-enabled external activities:
This interface provides all Cadence IDs for each Workflow Elements and theirs parameters.
Provided by bundle: org.polarsys.kitalpha.transposer.core
File name: org.polarsys.kitalpha.transposer.api.ITransposerWorkflow.java
Transposer provides main interfaces allowing to contribute / redefine the behaviour of Transposer.
This interface allows contributing a new Transposer Process using the Transposer Architecture.
Provided by bundle: org.polarsys.kitlpha.transposer.core
File name: org.polarsys.kitalpha.transposer.api.ITransposer.java
This interface defines objects allowing to de schedule rule application thanks to the dependency graph.
Provided by bundle: org.polarsys.kitalpha.transposer.scheduler
File name: org.polarsys.kitalpha.transposer.scheduler.api.IScheduler.java
This interface defines objects are responsible for rule discovery and rule inference.
Provided by bundle: org.polarsys.kitalpha.transposer.rules.handler
File name: org.polarsys.kitalpha.transposer.rules.handler.api.IRuleHandler.java
This interface defines Transposer tasks objects.
Provided by bundle: org.polarsys.kitalpha.transposer.scheduler
File name: org.polarsys.kitalpha.transposer.scheduler.api.ITransposerTask.java
Provided by bundle: org.polarsys.kitalpha.transposer.core
Extension point name: org.polarsys.kitalpha.transposer.rules.handler.mapping.
Contributing a set of rules is done through the following extension (in the bundle plugin.xml file). You can show below the extension point description:
Extension Declaration Attributes:
-
Id: The ID of the Transposer contribution. (mandatory) -
Name: The Name of the Transposer contribution.
Mapping Declaration Attributes:
-
MappingPurpose: The purpose of the Mapping. (mandatory) -
MappingName: The Name of the Mapping. -
Description: A quick description for users. -
Private: Allows to hide the mapping in the User Interface -
ExtendedMappingExtensionID: The extended Transposer Mapping by this one. -
DomainHelper: The Domain Helper class used by this mapping. -
Context: The Context class used by this mapping. If not provided then it’s the GenericContext class that will be used.
MappingPackage Declaration Attributes:
-
Name: The name of the MappingPackage. (mandatory)
MappingElement Declaration Attributes:
-
Name: The Name of the Mapping. (mandatory) -
ReuseExtendedElementDefaultPossibility: Defines if this MappingElement should reuse the DefaultPossibility definition extended by this one. -
ReuseExtendedElementPossibilities: Defines if this MappingElement should reuse the Possibilities definition extended by this one. -
DomainMetaClass: The domain class.
DefaultMappingPossibility or MappingPossibility Declaration Attributes:
-
Enabled: Define if the rule should enable or not. By default TRUE. -
Name: The Name of the DefaultMappingPossiblity element. -
CompleteRule: The standard rule to be used when no cycles occur on the model element we want to transpose. -
IncompleteRule: Rule to be used when cycles occurs. During model transformation, it allows continuing the process by creating a “stake holder” element, and the engine will “fill” this element at the end of the transformation.
Context May declare a local IContext that will complete the current one when this rule is executed. This IContext will “help” the rule do the job (cache queries results ...).
This interface specifies the contract for a Rule (complete or incomplete).
Provided by bundle: org.polarsys.kitalpha.transposer.rules.handler
File name: org.polarsys.kitalpha.transposer.rules.handler.rules.api.IRule.java
Provided by bundle: org.polarsys.kitalpha.transposer.rules.handler
File name: org.polarsys.kitalpha.transposer.rules.handler.rules.api.IDomainhelper.java
This project defines an architecture to insert specific actions in an execution process. Cadence uses the Eclipse architecture profits by exploiting the concept of plug-in.
The next schema shows an abstract description of the concepts introduced in Cadence.
This Cadence defines three important concepts:
- Workflow: a workflow is a process where several sub processes (p1, p2, …) are executed one after others;
- Workflow Element: a workflow element is a step in the workflow between a sub process and the next one;
- Activity: an activity is an independent program that can be launch between to subprocesses, i.e. at a workflow element.
In this schema we zoom on the workflow element and introduce the concept of parameters. The parameters in red are defined by the workflow element. All the activities that contribute for this workflow element receive these parameters. For instance a parameter could be a semantic model and an activity could be implemented to test and validate the model before another sub process execution. Obviously the activity can access to the semantic model and the workflow element has to declare it as a parameter.
Each activity may define its own parameters, represented in blue on the previous schema. These parameters are also defined for the activity.
Allows launching Cadence programmatically. It’s this class that your process should call in order to execute cadence.
Provided by bundle:org.polarsys.kitalpha.cadence.core
File name: org.polarsys.kitalpha.cadence.core.api.CadenceLauncher.java
This class allows getting activities, workflows, etc... contributing at the Cadence extensions points.
Provided by bundle:org.polarsys.kitalpha.cadence.core
File name:org.polarsys.kitalpha.cadence.api.CadenceRegistry.java
This class allows to launch a Cadence execution from the Eclipse UI or to get the Map of activities.
Provided by bundle:org.polarsys.kitalpha.cadence.ui
File name: org.polarsys.kitalpha.cadence.ui.api.CadenceUIRegistry.java
This class extends AbstractLaunchConfigurationTab and allows providing a tab for the Launch Configuration UI eclipse mechanism.
Provided by bundle:org.polarsys.kitalpha.cadence.ui
File name: org.polarsys.kitalpha.cadence.ui.api.CadenceTab.java
Cadence is an Eclipse plug-in that defined two extension points:
- Workflow extension point: permits to define a workflow and its workflow elements ;
- Activity extension point: permits to define activity related to a workflow element.
A program is identified as a workflow if it can be divided in sub processes. a workflow can define many Workflow elements. Many activities can be defined for one workflow element and an activity can be defined for several workflow elements.
Provided by bundle:org.polarsys.kitalpha.cadence.core
Extension point name: org.polarsys.kitalpha.cadence.workflow.declaration.
Contributing a workflow to a process is done through the following extension (in the bundle plugin.xml file):
<extension
point="org.polarsys.kitalpha.cadence.core.workflow.declaration">
<WorkflowDefinition
Identifier="org.polarsys.kitalpha.example.workflow.definition"
Name="Cadence Workflow Declaration Example">
<Description>
Description body text
</Description>
<WorkflowElement
AllowMultipleContributions="true"
Identifier="org.polarsys.kitalpha.example.workflow.element.definition"
Name="Workflow Element 1"
orderNumber="0">
<Description>
Description body text
</Description>
<ParameterDefinition
Name="Parameter 1"
Type="test.ParameterDefinition1">
<Description>
Description body text
</Description>
</ParameterDefinition>
</WorkflowElement>
</WorkflowDefinition>
</extension>
Only one workflow can be defined per extension.
Worflow Declaration Attributes:
-
identifier: The ID of the workflow. (mandatory) -
name: The Name of the Worflow. (mandatory) -
description: A quick description for users about the workflow. (optional)
Workflow Element Declaration Attributes:
-
identifier: The ID of the WorkflowElement. (mandatory) -
name: The Name of the WorflowElement. (mandatory) -
description: A quick description for users about the workflowElement. -
orderNumber: This attribute allows to sort WorkFlowElements by order.
ParameterDefinitionAttributes:
-
name: The Name of the Workflow. (mandatory) -
description: A quick description for users about the workflow. (optional) -
type: The type of the declared parameter (String, List, etc …)
Provided by bundle: org.polarsys.kitalpha.cadence.core
Extension point name: org.polarsys.kitalpha.cadence.core.activity.declaration. Contributing an activity to a workflow is done through the following extension (in the bundle plugin.xml file):
<extension
point="org.polarsys.kitalpha.cadence.core.activity.declaration">
<ActivityDeclaration
Identifier="org.polarsys.kitalpha.example.activity.contribution"
Multiple="false"
Name="My Contributed Activity"
ActivityClass=”org.polarsys.kitalpha.example.activity.MyActivity”
WorkflowElementIdentifier="org.polarsys.kitalpha.example.workflow.element.definition"
WorkflowIdentifier="org.polarsys.kitalpha.example.workflow.definition">
<Description>
Description body text
</Description>
</ActivityDeclaration>
</extension>
Activity Declaration Attributes:
-
Identifier: The ID of the Activity. (mandatory) -
Name: The Name of the WorflowElement. (mandatory) -
Description: A quick description for users about the workflowElement. Multiple-
WorkflowIdentifier: The ID of the contributed Workflow -
WorkflowElementIdentifier: The ID of the contributed WorkflowElement -
ActivityClass: The JAVA Class of the Activity (implements IActivity, see below)
This interface specifies the contract for providing activity.
Provided by bundle:org.polarsys.kitalpha.cadence.core
File name: org.polarsys.kitalpha.cadence.core.api.IActivity.java
This project defines architecture to contribute and define easily OCL or JAVA Constraints for any EMF Modeling project. Accuracy uses is based on the EMF Validation Framework and Eclipse architecture profits by exploiting the concept of plug-in.
Accuracy is an Eclipse plug-in that uses some kind files and defined an extension point. There are three important kinds of files:
- The configuration file: provides some information like, the severity level, message, etc. for your invariants in this file.
- The OCL files: you put the OCL Constraints in those files.
- The Java files: Each class checks one validation rule.
Here is an organization sample:
An OCL file contains one or more invariants (at your convenience).
constraint0001.ocl:
package extlibrary
context Library
-- we can define additional operations and attributes to assist
-- in the formulation of our constraints
def: unpublishedWriters : Set(Writer) = self.writers->select(books->isEmpty())
-- so, here we use one such definition
inv writers_have_written: unpublishedWriters->isEmpty()
endpackage
It is possible to use the Java Language to check rules. You have to write a Java Class that implements the IJavaConstraint contract (see below). The WriterNameStartsWithUpperCase is a sample:
public class WriterNameStartsWithUpperCase implements IJavaConstraint<Writer> {
public Class<Writer> getTargetType() {
return Writer.class;
}
public boolean isValid(Writer object) {
return object.getName() != null && object.getName().length() > 0
&& Character.isUpperCase(object.getName().charAt(0));
}
}
Provided by bundle : org.polarsys.kitalpha.accuracy
File name: org.polarsys.kitalpha.validation.java.provider.generic.IJavaConstraint.java
This file describes which constraints files have to be loaded, and for each invariant that will be found in OCL files and each provided JAVA constraints:
- Name.
- Message.
- Severity.
- Categories.
- Code.
When you write a new constraint, you just have to create the .ocl file in the good directory, and 'add' the constraint information in the properties file.
The properties file contains some more information :
- The common category to all constraints => that has to be the same or a sub-category of the one bound in the constraintBinding (see the Manifest Section)
- The folder where OCL files will be found Be sure that the CommonRootCategory is set to at least the category on the binding (or a sub category). if it is not , constraints probably won't be activated. The content of the file is separated into two parts:
- The header
- The constraints
The header of the configuration file contains the following data:
- CommonRootCategory: The common category for all constraints
- ConstraintsFolder: the folder that contains all OCL files
- ConstraintFiles: all OCL files name (without the OCL extension) separated with a comma.
Below a header of a configuration file:
#== Common category used for all constraints => necessary to be taken into account
#== by the Constraint Binding
CommonRootCategory=library/allConstraints
#== Folder where the constraints will be found.
ConstraintsFolder=OwnConstraints/Constraints/
#== The list of file names (separated by a ',') (without extension) that contain the invariants
#== having the message, severity, categories described in this file
ConstraintFiles=\
constraint0001,\
constraint0002
This part of the configuration file contains all constraints. A constraint specifies the following data:
-
Name: the name of the constraint. -
Message: the message to display when the constraint is not checked. -
Severity: the severity of the constraint (value between: NULL, INFO, WARNING, ERROR and CANCEL). -
Categories: the categories of the constraint (in addition of the common category). -
Code: the code of the constraint. Here is a sample of a constraint part of the configuration file:
#============= Constraint constraint0001/writers_have_written/Rule Type = OCL
# All writer shall have written at least one book
constraint0001.Invariant.writers_have_written.Name=LibraryConstraint#0001
constraint0001.Invariant.writers_have_written.Message=\
Library's writers should have written at least one book.
constraint0001.Invariant.writers_have_written.Severity=ERROR
constraint0001.Invariant.writers_have_written.Categories=library/writer
constraint0001.Invariant.writers_have_written.Code=0001
#============= Constraint constraint0001/writers_have_written/Rule Type = OCL
# Every book shall have an author
constraint0002.Invariant.book_must_have_author.Name=LibraryConstraint#0002
constraint0002.Invariant.book_must_have_author.Message={0} has no writer.
constraint0002.Invariant.book_must_have_author.Severity=ERROR
constraint0002.Invariant.book_must_have_author.Categories=library/book
constraint0002.Invariant.book_must_have_author.Code=0002
The key of information has the following pattern: OCL: <ocl_file_name>.Invariant.<invariant_name>.<data_to_set> Java: <requirement_id>.Invariant.<invariant_id>.<data_to_set>
Provided by bundle: org.eclipse.emf.validation
Extension point name: org.eclipse.emf.validation.constraintBindings.
Declaring a constraint category is done through the following extension (in the bundle plugin.xml file):
<extension
point="org.eclipse.emf.validation.constraintBindings">
<binding
category="library"
context="org.polarsys.kitalpha.accuracy.clientContext">
</binding>
</extension>
ConstraintBindings Declaration Attributes:
-
Category: To reference a single constraint category and all of the constraints that it includes -
Constraints: Do Not Use -
Context: References the ID of a context that is bound to one or more constraints. Always Use : « org.polarsys.kitalpha.accuracy.clientContext »
Provided by bundle: org.eclipse.emf.validation
Extension point name: org.eclipse.emf.validation.constraintProviders.
Declaring a validation rule mapping to metamodel is done through the following extension (in the bundle plugin.xml file):
<extension
id="ocl.constraint.provider.SpecificConstraintProvider"
point="org.eclipse.emf.validation.constraintProviders">
<constraintProvider
class="ocl.constraint.provider.SpecificConstraintProvider">
<package namespaceUri="http://org/eclipse/emf/examples/library/extlibrary.ecore/1.0.0">
</package>
</constraintProvider>
</extension>
ConstraintProvider Declaration Attributes:
-
Class: The Class provider class that will provide batch and live constraints. If you declare OCL Validation Rules, your provider should extend org.polarsys.kitalpha.validation.ocl.provider.generic.GenericOCLConstraintProvider If you declare JAVA Validation Rules, your provider should extend org.polarsys.kitalpha.validation.java.provider.generic.GenericJavaConstraintProvider
Package Declaration Attributes:
-
NamespaceUri: The namespace URI of an EMF package supported by the constraint provider.
Note : If you declaring JAVA Validation Rules, you have to contribute another extension point :
Provided by bundle: org.eclipse.emf.validation
Extension point name: org.polarsys.kitalpha.validation.java.