Constraints can be used to define additional restrictions for properties. Constraints can be defined
for single properties or sub-properties
between sub-properties of a single property
between properties of a single asset
and across different assets.
A constraint specified in a given asset can address external assets by exploiting
the access structure provided by the arcs between
assets.
If there is an arc leading from asset A to asset B, we can access properties in asset B from asset A. We do this by using the arc's role name to specify the property's access path. (If no role name is specified we use the name of the target asset, instead.) For example, when using XPath as a constraint language, we would write
B/propname
when no role name was specified, respective
rolename/propname
when a role name was specified..
Constraints can be specified with a context expression. For example, a constraint between sub-properties of a single property could specify the path of that property as context, and specify the sub-properties relative to that path:
name::(not(first) or (first and last))
Natural language. Easy to use, but tends to ambiguity.
OCL. Powerful, easy to translate into Java.
XPath. Well suited to our XMLish property structures.
Ideal,
when the model is implemented in XML: easy to translate into Schematron
rules.
Can be translated into Java, too.
A model may specify a default constraint language, or several constraint language prefixes. This allows the use of different constraint languages within the same model. Constraints that are formulated in a constraint language other than the default constraint language must be specified with a constraint language prefix which is separated from the rest of the constraint by a colon:
name::xpath:(not(first) or (first and last))
Optionally it is possible to decorate a constraint with a label. A constraint label does not have any specific purpose within AOM but helps to identify constraints. The label is separated from the rest of the constraint expression with a left curly bracket. Note, that there is no closing bracket.
c1{name::xpath:(not(first) or (first and last))
Abstract constraints are simply specified by an (optional) context, an (optional) label, and a constraint name. The concrete constraint depends on the implementation. In particular, abstract constraints allow to implement soft constraints (soft coded business rules). The names of abstract constraints constitute one or several vocabularies. The vocabulary used is specified with the constraint language prefix or by the default constraint language.
a1{name::myClang:constraint1
| Home | Definition | Step-by-Step | Examples | Downloads |
Contact: info@aoModeling.org