Page last modified 16:02, 30 Dec 2015 by Antero

3. OCL statement

    Table of contents

    Version as of 09:14, 25 Jan 2022

    to this version.

    Return to Version archive.

    View current version

    Description

    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 the situation in which the OCL-statement applies. simpleType or complexType
    • Property within context (e.g. XML element, attribute)
    • Manipulating qualities of a property (e.g. checking equality, arithmetic operations)
    • Logical operators between sections in the statement (and, or, xor, not, implies)

     

    Keyword "self" is used to refer to the element of the context. Dot notation is used to traverse the elements within schema tree.

    Practice

    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 valid case is depicted in the rule

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

     

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

    In OCL-statement, self is used to refer to element Header. Then dot notation is used to traverse the tree to locate the specific element. It's value is then compared against another string, depicted inside quotation marks.

     

    When an erreneous file against that rule is inserted to validation pipe, an error will be returned whenever Debtor Name is not the one defined in the statement.

    Examples

    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.

      <Header>
        <Id>1.0</Id>
        <TimeStamp>2015-07-03T12:17:50</TimeStamp>
        <ControlSum>2</ControlSum>
        <NumberOfTransactions>1</NumberOfTransactions>
        <Debtor>
          <Name>The initiator</Name>
        </Debtor>
      </Header>

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

      <Header>
        <Id>1.0</Id>
        <TimeStamp>2015-07-03T12:17:50</TimeStamp>
        <ControlSum>2</ControlSum>
        <NumberOfTransactions>1</NumberOfTransactions>
      </Header>

     

      <Header>
        <Id>1.0</Id>
        <TimeStamp>2015-07-03T12:17:50</TimeStamp>
        <ControlSum>2</ControlSum>
        <NumberOfTransactions>1</NumberOfTransactions>
        <Debtor>
          <Name>Something else</Name>
        </Debtor>
      </Header>

     

    Two cases being:

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

     

    One rule can only contain one error message, so in order to make the error messages as accurate as possible, this business rule has to be divided into two different 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
    OCL:

    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.

    Menu