MetaBoss Design Studio Guide.

Validation constraints overview.

Index

Introduction

Typically, most Entities, Structures and Operations have a restricted set of allowed values (ie. Attribute values for Entities, Field values for Structures and Input Field values for Operations). These model elements only make sense and work properly within this subset of the possible values. Error condition occurs if any other combination is attempted.

The definition of such valid set of values forms very important part of the model and is maintained as a set of validation constraints (ie. rules) attached to the model elements restricted by these constraints. Obvious benefit of defining constraints is better, more precise, definition of the system. The other benefit is the ability to automatically generate code which checks values against constraints at the run-time and triggers error condition if necessary.

Constraints are not MetaBoss's invention. The UML Specification allows for constraints to be attached to model elements. This specification also specifies Object Constraints Language (OCL) - the preferred language used to specify constraints. In MetaBoss model constraints are only allowed to be attached to Entities, Structures and Operation Input Fields. This restriction is there simply because it does not make sense to specify validation constraits anywhere else in the Enterprise Model. (Remember that the MetaBoss model is specialised to better describe Enterprise Systems and not any System in the world as in case of UML model).

Operation Input Constraints

Operation Input Constraints are attached to operations. The OCL expression is interpreted in the context of the Operation Input Fields. This means that all top level object names in the OCL expression must correspond to the names of the Input Fields in the Operation. The picture below shows example of typical Operation Input constraint.

The OCL expression in this particular constraint specifies that the 'CourseKey' input field may not be undefined (i.e. null or empty). In addition every constraint defines the error message to be returned to the caller if constraint has not been satisfied. For this type of constraint error usually occurs when someone has invoked this Operation with invalid inputs.

Structure Constraints

Structure Constraints are attached to Structures. The OCL expression is interpreted in the context of the Structure Fields. This means that all top level object names in the OCL expression must correspond to the names of the Fields in the Structure.

Similarly to the Operation Input constraints the Structure constraints are checked at the time when Operation is invoked (this is of course providing that the Structure is included in the Operation Input). In fact Structure fields can be validated using Operation Input constraint instead of Structure constraint. There is, however, substantial difference between these two methods and both of them have use in the model. The Structure constraint is verified regardless of the Operation (in other words it is verified during invocation of any Operation which uses this Structure in it's input). Operation Input constraints are only verified when certain operation is invoked.

The picture below shows example of typical Structure constraint.

The OCL expression in this particular constraint specifies that at least one of the fields 'Code' and 'InstanceId' must be defined (i.e. not null or empty). In addition every constraint defines the error message to be returned to the caller if constraint has not been satisfied. For this type of constraint error usually occurs when someone has passed invalid Structure to any Operation.

Entity Constraints

Entity Constraints are attached to Entities. The OCL expression is interpreted in the context of the Entity the constraint is attached to. This means that all top level object names in the OCL expression must correspond to the names of the Attributes or References in the Entity. In addition, since Entity may have State Machine and therefore be in certain State at the certain time, the Entity constraint specification may include reference to the Entity state.

The Entity constraints are checked every time immediately before saving changes to the Entity instance (i.e. prior to transaction commit). The picture below shows example of typical Entity constraint.

The OCL expression in this particular constraint specifies that the 'RejectionReason' attribute of the 'Order' entity must be populated when entity is in the 'Rejected' state. In addition every constraint defines the error message to be returned to the caller if constraint has not been satisfied. For this type of constraint error usually occurs when someone attempts to save the Entity which has not been modified correctly.