3. OCL statement
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. 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.
|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.
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.
However, there are two different possible cases which would not pass the rule
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"
|OCL:||self.Debtor.Name->size() = 1|
|Description:||Rule mandates Debtor name|
self.Debtor.Name->size() = 1 implies
self.Debtor.Name = "The initiator"
|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