A business rule is a written statement specifying what a system must do or how it must be structured. Rules can be derived from a government-imposed law, a customer requirement, or an internal guideline. You can attach rules to your model objects to complement your diagrams with information that is not easily represented graphically.
For example, a rule stating that "An employee belongs to only one division." can help you graphically build the link between an employee and a division. Rules often start as simple observations that develop, during the design process, into more detailed expressions. You may, for example, develop rules to explicitly define what information a customer supplies when placing an order, or how much a customer can spend based on a credit limit.
Rules can be developed from procedures that the system must respect, specifications dictating the scope of the project, and external constraints.
Business rules can have the following properties:
Property |
Description |
---|---|
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:
|
Server expression/ Client expression | Though business rules typically start out as descriptions, as you develop your model and analyze your business problem, you can enrich them by adding technical expressions. |