2.5.6 Constraints tab
In addition to the rules given in bindings and their role
cardinalities, it is possible to define additional constraints on relationship,
role, port and object combinations.
To specify the constraints, select the
Constraints
tab in the Graph Tool.
The tab shows the constraint
definitions of this graph type (
Figure
2–11).

Figure 2–11. Constraint definitions.
Constraints can
be set for:
 | Object
connectivity in the binding (e.g. an object may be in a certain role at most
a specified number of
times). |
 | Object
occurrence (e.g. an object type may have only a specified number of
instances in a
graph) |
 | Ports
involved in binding (e.g. all ports of a specified type in a binding must
have the same value for a specified
property) |
 | Property
uniqueness (e.g. all objects of a certain type in a graph must have unique
values for a specified property). |
To create a
constraint, select the type of constraint from the Add Constraint For
list and press Add (or alternatively select Add... from the
Constraints Definer pop-up menu). This will open a dialog where you can enter
the constraint parameters for the selected constraint type. To edit an exiting
constraint, double-click it in the list of constraints (or select it and press
the Edit button). To delete a constraint, select it and press
Delete. The Edit... and Delete commands are also available
in the Constraint Definer’s pop-up menu.
Connectivity constraints
A connectivity constraint is defined for an object type, and
limits how many times each instance can take part in a given type of role or
relationship. An example of a constraint with a role type is the definition of
the Family relationship in Family Tree diagrams. It defines that each Person can
be in only one Child role (i.e. each Person can be a Child of only one set of
parents). An example of a relationship connectivity constraint would be that a
Process in a Data Flow Diagram could be connected to at most 10 Data Flows: a
common rule to prevent overly complicated diagrams.
A connectivity constraint applies only within a single
graph of this graph type. Hence, an object may be in more than the specified
number of roles or relationships in total over the whole repository, e.g. a
Person can be in one Parent role in one graph, and another Parent role in
another graph.

Figure 2–12. Defining connectivity constraints.
The
elements of the constraint are specified in the four fields of the Connectivity
Constraint Definer window. The top field allows you to select the object type
for the constraint from a pull-down list. The second field specifies the upper
limit for the constraint: the initial value is one (if no constraint is defined,
there is no upper limit).
The radio buttons below determine whether the constraint
is related to role types or relationship types, changing the contents of the
pull-down list below. After choosing the correct radio button, you can choose
the relationship or role type from the bottom list.
Occurrence constraints
Occurrence constraints limit the number of instances a
specified object type can have in a graph. A typical example for an occurrence
constraint is the start state of a state diagram – there may be only one
start state in each state diagram. Similarly, this constraint can be used to
limit the complexity of a graph by setting the maximum amount of instances for
each specific object type.

Figure 2–13. Defining occurrence constraints.
The
occurrence constraints are defined in the Occurrence Constraint Definer window.
The constrained object type is defined in the topmost field while the maximum
number of occurrences is defined in the lower
field.
Port
constraints
Port constraints limit the set of possible port instances that
can be part of a binding according to their property values. For example, a
signal processor could have several ‘Signal’ ports for various
signal paths. Each port would carry properties ‘Direction’ (with
values ‘In’ or ‘Out’) and ‘Signal type’
(with values ‘Analog’ or ‘Digital’). Now, if we would
like to have a binding that represents legal signal paths (i.e. signal must flow
from ‘Out’ port to ‘In’ port and have the same signal
type), the following port constraints must be set:
 | All
ports of type ‘Signal’ in the binding must have a different value
for the ‘Direction’
property |
 | All
ports of type ‘Signal’ in the binding must have the same value for
the ‘Signal type’ property |

Figure 2–14. Defining port constraints.
A port
constraint is specified in the three fields of the Port Constraint Definer
window. The top field allows you to select the port type for the constraint from
a pull-down list. The constraint applies to all ports that are of this type or
any of its descendants. The radio buttons below the port type field determine
whether the constraining property should have the same or different value within
the binding. The local name of the constraining property is then entered into
the field at the bottom of the window.
If a port is of the specified type or any of its
descendants, but does not have a property whose local name matches that
specified in the constraint, an empty string will be taken as the property value
for that port. All port property values are compared as strings, regardless of
the data type of the property.
Uniqueness constraints
Uniqueness constraints can be used to define that a certain
property must have unique values in all instances of a specific object type in a
graph. For example, state names in WatchApplication graphs or class names in UML
Class Diagrams must be unique (i.e. there can not be another state or class with
the same name within the same graph).

Figure 2–15. Defining uniqueness constraints.
Uniqueness
constraints are defined in Uniqueness Constraint Definer window. The top field
of the window defines the object type the constraint applies to and the lower
field defines the property whose value must be
unique.