A constraint is an expression that constrains the semantics of an element, and it must always be true, or in other words, it is a restriction on an element that limits the usage of the element. A constraint is either declared in the tool and repeatedly used in several diagrams or identified and applied as needed in a diagram, for example:
Certain kinds of constraints (such as an association xor constraint) are predefined in UML, others may be user-defined. This can be a formal expression (OCL) or a semiformal or human-language formulation.
- A constraint is one of three UML’s extensibility mechanisms: Steretypes, Tagged Values and Constraints. A constraint extends the semantics of a UML building block, allowing you to add new rules or modify existing ones.
- A constraint is a condition (a Boolean expression) that restricts the extension of the associated element beyond what is imposed by the other language constructs applied to that element.
UML Constraint Examples
A constraint specifies conditions that must be held true for the model to be well-formed. As I mentioned before, constraints may be written as free-form text. If you want to specify your semantics more precisely, you can use the UML’s Object Constraint Language (OCL) as shown in the following class diagram:
A constraint is rendered as a string enclosed by brackets and placed near the associated element. This notation is also used as an adornment to the basic notation of an element to visualize parts of an element’s specification that have no graphical cue.
For example, some properties of associations (order and changeability) are rendered using constraint notation.
Constraints for Class Operations
You might want to constrain the EventQueue class so that all additions are done in order as shown in the figure below. You can add a constraint that explicitly marks these for the operation add.
Constraints in a Note
Notes are the mechanism provided by the UML to let you capture arbitrary comments and constraints to help illuminate the models you’ve created. Notes may represent artifacts that play an important role in the software development life cycle, such as requirements, or they may simply represent free-form observations, reviews, or explanations.
Constraints in Class Dependency
This diagram shows that each Person may be a member of zero or more Departments and that each Department must have at least one Person as a member. This diagram goes on to indicate that each Department must have exactly one Person as a manager and every Person may be the manager of zero or more Departments.