Project:
|
![]() Figure 1P-08 - Conceptual PolicyRule : Class diagram
The purpose of this section is to show how the Policy model can be used to represent policy in a standard format that is independent of the content of the PolicyRule.<br/>As stated previously, a PolicyRule is a triplet, containing an event clause, a condition clause, and an action clause. In addition, a PolicyRule itself has additional data and metadata that enable behavior to be associated with a PolicyRule. Conceptually, a PolicyRule can be thought of as follows:<br/>In the simple representation shown in Figure 1P- 6. A Conceptual Representation of a PolicyRule, a PolicyRule is really an intelligent data container that serves to aggregate one or more PolicyEvents, one or more PolicyConditions, and one or more PolicyActions. Note that the cardinality of the three aggregations that define the characteristics of this intelligent data container (i.e., PolicyConditionInPolicyRule, IsTriggeredBy, and PolicyActionInPolicyRule) are each 1..n on the composite side. This means that a PolicyRule must contain at least one or more PolicyConditions, PolicyEvents, and PolicyActions in order to be instantiated. Since the cardinality of these three aggregations is 0..n on the aggregate side, this means that a PolicyCondition, a PolicyEvent, and a PolicyAction can exist on their own without being bound to a PolicyRule. This enables PolicyEvents, PolicyConditions, and PolicyActions to be designed and stored in a PolicyRepository and then bound to a PolicyRule at run-time.<br/>This is a very important point, as it enables the concept of reusable Policy components to be defined. This is discussed later in this Addendum in the section titled Reusable vs. Ad-Hoc Policy Entities.<br/>
|