User Manual    [Previous]   [Next]   

Model Constraints

Constraints can be used to assert that certain properties of the model are as expected, as shown in the examples below. Associations, attributes and generalizations can be checked.

Why would model constraints be useful, given that a programmer can just inspect the code to see if there are statements declaring the facts in question? The answer is that Umple has sophisticated separation of concerns mechanisms including traits, mixins and mixsets, and the developer may not be completely sure that a given model constraint will always be true. An attribute, for example, might be only introduced into the class in a completely different file or mixset, and the developer may not be certain that the file or mixset is being included. Using a model constraint allows a developer who wants to use that attribute in a method to cause an Umple compilation error if it does not in fact exist, rather than waiting to see if Java code fails to compile.

Below is an example of a model constraint, but there are other examples in the manual pages that give help about the error messages raised by these constraints:

• Assertion that an attribute of a certain name (defined elsewhere) must exist in this class
• Assertion that an attribute of a certain type must exist
• Assertion that this class is a subclass of another (with the isA statement defined elsewhere)
• Assertion that this class is a superclass of another class (with the isA statement defined in that class)
• Assertion that an association exists between two classes

Example

class X {
  // Checks that this class has an association
  // with class Z.
  [model: -- Z]
}

class Y {
  isA X;
  // Verifies that this is a subclass of X
  [model: isA X]
}

class Z {
 a;
 1 -- * X;
 // Verifies that there is an association a
 [model: has a] 
}
      

Load the above code into UmpleOnline