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).

Constraints can be set for:

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.

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.

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 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.

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 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:

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 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).

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.