Defining and Validating Constraints

Navigation: Populating your architecture > Validation >

Understanding and Defining Constraints

The structure and properties of an architecture can be restricted by using constraints. Constraints can be applied to component types and connection types to restrict the structure of an architecture in two ways. The first way is to restrict the hierarchy by defining "parent should/must have child" and "child should/must have parent" relationships. The second way is to restrict the topology by defining "component should/must be attached to connection" and "connection should/must be attached to component" relationships. Furthermore, constraints can be applied to the properties of component types, connection types, templates, viewpoints, architectures, diagrams and 3D views to restrict the architecture(s) in two additional ways. The first way is to set the data type of the property to restrict the valid values that it can have, namely; Text, Integer, Decimal, Date/Time, Boolean or List. The second way is to set the required status of the property to indicate whether a value needs to be entered for the property (Note: Required constraints only apply to properties for component and connection types). Further information on property constraints is provided in the Changing the properties of a component, connection or type help topic. Once constraints have been defined, it is possible to validate an architecture against the constraints. ABACUS will warn about any constraints that have been violated.

The key to determining which constraint(s) to define lies in the exact language used to describe the constraint. For hierarchy constraints they are typically of the form "nouns can/should/must be decomposed into n nouns" or "nouns can/should/must be aggregated by nouns" etc. For example, "Departments must be decomposed into Teams" or "Applications can be decomposed into Modules". For topology constraints they are typically of the form "nouns can/should/must verb nouns". For example, "Processes can be performed by Teams" or "Applications are hosted on Servers". Now, you can see in each constraint there are various can/should/must 'qualifiers' and these can be of 3 types;

•Recommended - These will typically use words/phrases like; "should", "recommended", "advised" etc.

•Mandatory - These will typically use words/phrases like; "must", "is", "are", "has", "shall" etc.

Depending on the type of constraint (hierarchy or topology) and the qualifiers used in describing it, specific constraint(s) should be defined (see below). For the above hierarchy example of "Departments must be decomposed into Teams" one should define a "Parent must have Child" constraint and set the enforcement to be Enforced. For the above topology example of "Processes can be performed by Teams" one should only create two (2) "Connection must be attached to Component" constraints for either end of the performed by connection type. Specifically, the following constraints are recommended to be defined (see below) for the various options;

•Hierarchy constraints;

oNouns A can be decomposed into Nouns B, or Nouns B can be aggregated by Nouns A or Nouns B should be aggregated by Nouns A - Define a "Child must have Parent" constraint with the child type as Noun B, parent type as Noun A and enforcement as Warned.

Note

This means that if a child exists, it should have a parent of a certain type. If not, you will get a warning.

oNouns A should be decomposed into Nouns B - Define a "Parent must have Child" constraint with the parent type as Noun A, child type as Noun B and enforcement as Warned.

Note

This means that if a parent exists, it should have children of a certain type. If not, you will get a warning.

oNouns A must be decomposed into Nouns B - Define a "Parent must have Child" constraint with the parent type as Noun A, child type as Noun B and enforcement as Enforced.

Note

This means that if a parent exists, it must have children of a certain type. If not you will get an error.

oNouns A must be aggregated by Nouns B - Define a "Child must have Parent" constraint with the child type as Noun A, parent type as Noun B and enforcement as Enforced.

Note

This means that if a child exists, it must have a parent of a certain type. If not, you will get an error.

•Topology constraints;

oNouns A can be verb Nouns B - Define two (2) "Connection must be attached to Component" constraints. The first being with the Source end of connection type verb attached to Noun A component type and enforcement set to Enforced. The second being with the Sink end of connection type verb attached to Noun B component type and enforcement set to Enforced.

Note

This means that if the connection exists, it must connect components of certain types. If not you will get an Error. Overall this ensures that these components can still exist and not be connected to each other. However if they are connected, connections of the right type must be used.

oNouns A should be verb Nouns B - Define two (2) "Component must be attached to Connection" constraints. The first being with Noun A component type attached to the Source end of the verb connection type and enforcement set to Warned. The second being with Noun B component type attached to the Sink end of the verb connection type and enforcement set to Warned. Additionally, define two (2) "Connection must be attached to Component" constraints. The first being with the Source end of connection type verb attached to Noun A component type and enforcement set to Enforced. The second being with the Sink end of connection type verb attached to Noun B component type and enforcement set to Enforced.

Note

This means that if components of either type exist, they should be attached to a connection of a certain type. If not you will get a warning. In addition, this means that if the connection exists, it must be connected to components of the specified type. If not you will get an error. Overall this ensures that if components of these types exist, you will get warnings if they are not connected to each other.

oNouns A must be verb Nouns B - Define two (2) "Component must be attached to Connection" constraints. The first being with Noun A component type attached to the Source end of the verb connection type and enforcement set to Enforced. The second being with Noun B component type attached to the Sink end of the verb connection type and enforcement set to Enforced. Additionally, define two (2) "Connection must be attached to Component" constraints. The first being with the Source end of connection type verb attached to Noun A component type and enforcement set to Enforced. The second being with the Sink end of connection type verb attached to Noun B component type and enforcement set to Enforced.

Note

This means that if components of either type exist, they must be attached to a connection of a certain type. If not you will get an error. In addition, this means that if the connection exists, it must be connected to components of the specified type. If not you will get an error. Overall this ensures that if components of these types exist, you will get errors if they are not connected to each other.

To define a constraint

1.Ensure you have an ABACUS file open and the Explorer Window displayed.

2.In the explorer tree expand Types | Component Types or expand Types | Connection Types.

3.Right-click a component type or a connection type and select Add Constraint.

Adding a constraint

To define a hierarchy constraint, where a parent must have a specific child

4.On the Add Constraint window tick the Create Constraint checkbox under the Parent Must Have Child Constraint area.

5.Select the component type from the drop-down box that you want to specify as the child of the component type selected in step 3.

Note

If there is already an enabled 'Parent Must Have Child' constraint defined for the parent component type and another child component type then this new constraint will be treated as an 'AND'. That is the type must be a parent of child type A and child type B, to whatever enforcement level (e.g. Disabled, Warned or Enforced - see step 7) is specified for each constraint.

6.Optionally you can define the minimum and maximum number of components of the component type specified that must be children of the component type right-clicked in step 3.

7.Choose whether you want the constraint to be Disabled, Warned or Enforced.

Note

Disabled constraints will be ignored from constraint validation, Warned constraints will produce a Warning in the Validation window if they are detected and Enforced constraints will produce an Error in the Validation window if they are detected. Furthermore, all Errors must be resolved before a Collaboration Server project can be committed. Constraints can be ignored on a per-Architecture basis by selecting the Disable Constraints option via the context menu on Architectures as seen in the Validate constraints figure, and will prevent the architecture from producing warnings, errors and locking users from committing Collaboration Server projects.

8.Click OK.

Note

The constraint will be displayed in the explorer tree under the component type right-clicked in step 3. The arrow denotes the direction of the constraint and in this case will point down and right. The padlock is coloured according to whether the constraint is Disabled (grey), Warned (yellow) or Enforced (red).

Parent must have child warned constraint

To define a hierarchy constraint, where a child must have a specific parent

4.On the Add Constraint window tick the Create Constraint checkbox under the Child Must Have Parent Constraint area.

5.Select the component type from the drop-down box that you want to specify as the parent of the component type right-clicked in step 3.

Note

If there is already an enabled 'Child Must Have Parent' constraint defined for the child component type and another parent component type then this new constraint will be treated as an 'OR'. That is the type must be a child of parent type A or parent type B, and the enforcement level (e.g. Warned or Enforced - see next step) should be the same otherwise enforced constraints will always override warned ones.

6.Choose whether you want the constraint to be Disabled, Warned or Enforced.

Note

7.Click OK.

Note

The constraint will be displayed in the explorer view under the component type chosen in step 5. The arrow denotes the direction of the constraint and in this case will point up and left. The padlock is coloured according to whether the constraint is Disabled (grey), Warned (yellow) or Enforced (red).

Child must have parent warned constraint

To define a topology constraint, where a component must be attached to a specific connection

4.On the Add Constraint window tick the Create Constraint checkbox under the Component Must Be Attached Constraint area.

5.Select the connection type from the drop-down box that you want to specify as the attached connection of the component type right-clicked in step 3. (Or select the component type from the drop-down box that you want to specify as the attached component if in step 3 you right-clicked a connection type.)

Note

If there is already an enabled 'Component Must Be Attached' constraint defined for the component type and another connection type then this new constraint will be treated as an 'AND'. That is the component type must be attached to connection type A and connection type B, to whatever enforcement level (e.g. Disabled, Warned or Enforced - see step 7) is specified for each constraint.

6.Optionally you can select a connection role that you want to add to the constraint. Select the specific role (i.e. either Source or Sink) from the drop-down box.

7.Choose whether you want the constraint to be Disabled, Warned or Enforced.

Note

8.Click OK.

To define a topology constraint, where a connection must be attached to a specific component

4.On the Add Constraint window tick the Create Constraint checkbox under the Connection Must Be Attached Constraint area.

Note

If there is already an enabled 'Connection Must Be Attached' constraint defined for the connection type and another component type using the same connection role (i.e. either Source or Sink), then this new constraint will be treated as an 'OR'. That is the connection type must be attached to component type A or component type B, and the enforcement level (e.g. Warned or Enforced - see step 7) should be the same otherwise enforced constraints will always override warned ones. Note also, that if there are multiple constraints that have the connection role specified as 'Any' (as opposed to specifically Source or Sink) then each end of the connection must be attached to one of the component types specified in the constraints.

6.Optionally you can select a connection role that you want to add to the constraint. Select the specific role (i.e. either Source or Sink) from the drop-down box.

Note

Either a Source or Sink role needs to be explicitly selected for an Attachment column to be available to be shown in a component catalogue.

7.Choose whether you want the constraint to be Disabled, Warned or Enforced.

Note

8.Click OK.