Name/Code/Comment
|
Identify the object. The name should clearly convey the object's purpose to non-technical users, while the code, which is used for generating code or scripts, may be abbreviated, and should not normally include spaces. You can optionally add a comment to provide more detailed information about the object. By default the code is generated from the name by applying the naming conventions specified in the model options. To decouple name-code synchronization, click to release the = button to the right of the Code field.
|
Stereotype
|
Extends the semantics of the object. You can enter a stereotype directly in this field, or add stereotypes to the list by specifying them in an extension file.
|
|
Type
|
Specifies the nature of the business rule. You can choose between: -
Constraint – a check constraint on a value. For example, "The start date should be inferior to the end date of a project." In a PDM, constraint rules attached to tables or columns are generated. If the DBMS supports multiple constraints, constraint rules are generated as separate constraint statements with the name of the rule.
-
Definition – a property of the element in the system. For example; "A customer is a person identified by a name and an address".
-
Fact – a certainty in the system. For example, "A client may place one or more orders".
-
Formula – a calculation. For example, "The total order is the sum of all the order line costs".
-
Requirement – a functional specification. For example, "The model is designed so that total losses do not exceed 10% of total sales".
-
Validation – a constraint on a value. For example, "The sum of all orders for a client must not be greater than that client's allowance". In a PDM, validation rules attached to tables or columns are generated as part of the primary constraint for the table or column.
|
Keywords
|
Provide a way of loosely grouping objects through tagging. To enter multiple keywords, separate them with commas.
|