Page last modified 13:26, 7 Jan 2016 by juhako

3. OCL statement

    Version as of 17:27, 23 Jan 2022

    to this version.

    Return to Version archive.

    View current version


    OCL-statement is the part of the rule containing a formal description of a business rule, defined in OCL language.

    Following items are related to OCL-statement in XMLdation service:

    • Context - defines which part of the XML message is being checked by the OCL-statement. simpleType or complexType
    • Property within context (e.g. XML element, attribute)
    • Manipulating qualities of a property (e.g. arithmetic operations, comparisons)
    • Logical operators between sections in the statement (and, or, xor, not, implies)
    Boolean returns and OCL-statement example

    Rule is written so that it matches the business rule it is depicting.

    For example, when a business rule is:

    Debtor name must be "The initiator"

    OCL-restriction is written in same form, so that the statement depicts a valid case, and thus valid case will not give an error in the validation phase. Error is only returned when the check does not pass.

    Context: HeaderType1
    OCL: self.Debtor.Name = "The initiator"
    Description: Rule defines a specific value for Debtor/Name.
    Message Debtor / Name is not The initiator


    This rule locates element Debtor / Name under HeaderTYpe1 and compares it's value to another value.

    Property within context

    For reference, below is an image representation of type HeaderType1. Note that context of the above example rule is not PartyIdentification nor Max140Text. HeaderType1 is the first unique mandatory type present in XML for referencing Debtor content.

    In OCL-statement, keyword "self" is used to refer to element Header. Then dot notation is used to traverse the tree to locate the specific element.


    Manipulating qualities of property

    In the example above, property's (self.Debtor.Name) value is compared against another string, depicted inside quotation marks. Notation used to depict comparisons are: =, <, >, =>, =<, <>. Explanations for these can be found in comparison wiki page.

    Arithmetic operators may be used when applicable as well.

    Logical operators

    Within the statement, logical operators (and, or, xor, not) may be used to alter the behaviour of the rule or to present a condition which has to pass before something else is checked (implies).


    Let's have a more thorough look at the business rule depicted above, 'Debtor name must be "The initiator"'. This business rule looks simple, but it contains two different rules. Following example scenarios are possible to be given:

    The XML snippet below would the pass check.

          <Name>The initiator</Name>

    However, there are two different possible cases which would not pass the rule



          <Name>Something else</Name>


    Two cases being:

    • Debtor name is not present at all
    • Debtor name is something else than defined in the business rule

    To separate these two different cases it makes sense to create two different OCL-rules. Creating multiple rules instead of one first sounds like making things more complicated, but it's rather vice versa. There are multiple benefits from this: each individual rule will be simple and clear, there are no hidden behavior inside any of the individual rules, error messaging in the validation can be made very accurate, documentation of the rules also becomes very accurate. So in this case we need these two OCL-rules:

    • Debtor name is mandatory
    • When Debtor name is given, its value must be "The initiator"


    Context: HeaderType1
    OCL: self.Debtor.Name->size() = 1
    Description: Rule mandates Debtor name


    Context: HeaderType1

    self.Debtor.Name->size() = 1 implies

    self.Debtor.Name = "The initiator"

    OCL-Query self.Debtor.Name
    Description: Rule restricts the value of Dbtr Nm when it is given


    Note that in the second rule, OCL query is defined as well.

    In addition, the schema contains two occurrences of Debtor, under Header and under Transaction. In this example an assumption is made that checking the Debtor under Header is enough.


    When handling elements within context which have a multiplicity higher than 1 (0..n or 1..n), they have to treated as a collection, and the collection type must be stated when writing the statement

    Collection types available are:

    • Bag - no order, may contain duplicates
    • Set - no order, duplicates removed   
    • OrderedSet - ordered, duplicates removed
    • Sequence - ordered, may contain duplicates