QMMM

The Visual Business Policy & Rule Modeling Layer (see top left of Fig. 5.1) allows to model business policies and business rules using the process-oriented enterprise on-tology framework [MHJS09] and application ontologies of an enterprise. Apart from describing business policies in natural language, this layer allows the users to model the context of a business policy using elements defined in application ontologies, and to define its implementation using available business rules and other business policies from the repository. Finally, this layer formalizes modeled business policies as instances of the Business Policy and Rule Ontology (BPRO) [MHJS09], which is discussed in the next section.

Business Policy and Rule Ontology

The most important concepts, attributes and relations in BPRO which are relevant to our work are shown in Fig. 5.2 as a class diagram using the stereotype extensibility mechanism of UML [Obj07].

Figure 5.2: A fragment of Business Policy & Rule Ontology (BPRO)

5.3 Approach 85

In addition to standard attributes such as PolicyName and NaturalLan-guageDescription, a business policy integrates with other enterprise sub-models us-ing the hasContext relation (see right bottom of Fig. 5.2). Usus-ing this relation, one can capture rationale for existence of a business policy by connecting it to a goal or strategy defined in the motivational model of an enterprise. Similarly, by con-necting to other enterprise sub-models one can capture the applicability situation for a business policy. For example, one can restrict the scope of a business pol-icy’s applicability by associating a business policy to a particular business function or organizational unit within an enterprise. This addresses the requirement (Req.

4) regarding the integration of business policy models with other enterprise sub-models. Requirement (Req. 6) regarding the capture of contextual information of business processes and business policies is addressed partially with respect to busi-ness policies and later we show how contextual information with respect to busibusi-ness processes is captured to fulfill the requirement completely.

A business policy can be composed of other business policies using the relation containsPolicy (see top right of Fig. 5.2) and/or business rules which implement it using relation implements (see center of Fig. 5.2). For example, a high level business policy can be composed of many low level operational business policies which are in turn implemented as business rules. Business rules are more formal compared to business policies and hence it is possible to automatically verify business policies in terms of business rules against business process models. Similarly, a business rule can trigger other dependent business rules using the relation callsBusinessRule when executing it (see top left of Fig. 5.2). The WSML representation of the BPRO ontology is provided in Appendix F.

Visual Modeling of Business Policies and Rules

Maier [Mai03] identified the need for a visual rule editor as one of the software tools to support ontology-based integration. Maier envisioned that a visual rule editor would allow for visual modeling of rules by dragging and dropping elements de-fined in an ontology. Following [Mai03], the Visual Business Policy & Rule Modeling Layer (see top left of Fig. 5.1) provides a set of visual elements (cf. Appendix H) for modeling a business policy/rule. As there is no restriction to building business rules using elements from any particular ontology, business rules constraining not only process models but also any other enterprise sub-model, can be built using el-ements defined in any ontology from the repository. Hence, the requirement (Req.

5) for supporting the specification of business rules for other enterprise sub-models is fulfilled. Therefore, a business rule can be formed involving concepts from multi-ple enterprise sub-models and similarly a business policy can include business rules constraining many enterprise and process models.

In the following two sections, we discuss the visual modeling of business policies and rules, respectively, in more detail.

Visual Modeling of Business Policies (see Fig. 5.3) involves three activities namely the modeling of its context, linking implementing business rules and linking lower level business policies. A policy modeler performs all of these three activities using the instances defined in various enterprise ontologies. The modeling layer finds the appropriate visualization construct (cf. Appendix H) for an instance via

Figure 5.3: Business Policy Modeling

logical reasoning. For example, if the chosen element is an instance of the concept Rule, then the business rule visual construct is used. Instances which do not belong to the concepts Policy and Rule are considered as the context of the modeled policy (see Fig. 5.3). Therefore, the users do not have to explicitly specify the relation as it is inferred via logical reasoning based on the types of the connecting elements (see Fig. 5.3, right). The connector (cf. Appendix H) in the case of business policies mod-eling is used for connecting different visual elements, and there is no differentiation as in the case of business rules modeling in terms of head and body connectors. The modeled business policy is formalized in the form of an ontology instance of the Business Policy & Rule Ontology. The formalization process starts with checking for modeling errors such as isolated edges, isolated nodes, etc. If there are no modeling errors in the policy model, then the relation instances based on the elements used in the model (e.g. business rules, context etc.) are determined. Finally, a BPRO ontology instance is created with an instance of the concept Policy, representing the currently modeled policy and the relation instances determined in the previous step.

The formalization process of a business policy addresses our requirement (Req. 3) regarding the need for automatic transformation of visually modeled business poli-cies into a formal machine-readable representation. In the end, both the graphically modeled and the formalized business policy are persisted separately in the Business Policies & Rules Repository.

Visual Modeling of Business Rules is similar to business policy modeling, the ad-ditional part being the visual formulation of business rules through the combination of the visual representation of an atomic expression (see Table H.2 in Appendix H) by using different visual connector constructs (see Table H.1 in Appendix H). Fig.

5.4 shows the visual modeling of a business rule corresponding to the following WSML-Flight inference rule:

worksIn(?e,?b) :−?ememberOf Employee and ?a memberOf Activity and ?b memberOf BusinessFunctionand performs(?e,?a) and belongsTo(?a,?b)

5.3 Approach 87

Constraint modeling is similar to inference rule modeling (see Fig. 5.4), with the difference that the constraints do not contain a conclusion part. Fig. 5.4 also shows the use of variables representing instances of the corresponding concepts.

Figure 5.4: Business Rule Modeling

The formalization of business rule formulation as an axiom is done by the Busi-ness Policy & Rule Formalization Layer and starts with checking for modeling errors such as isolated edges, isolated nodes, etc. If the business rule formulation does not contain any modeling errors, the set of atomic expressions for the conditions represented as the body is determined, formulated and combined using the con-junction operator. The same procedure is repeated for the head or conclusion part provided that the rule is of type inference and not constraint. Finally, the WSML-Flight logical expression obtained as an axiom is checked against the WSML-WSML-Flight grammar. The formalization of a business rule model is similar to that of a busi-ness policy model except that the names of the relations are callsBusibusi-nessRule for the grouping of business rules and usesElement for the elements used in the formulation of a business rule. In addition, the formalization process involves the addition of the obtained axiom in the ontology. This finally completes our requirement (Req. 3) that addresses the need for automatic transformation of a visually modeled business rule into a formal machine-readable representation. The graphically modeled busi-ness rule and its formal representation are stored separately in the Busibusi-ness Policies

& Rules Repository.

Note that the formal language specification for business policies and rules is pro-vided by the underlying formal logics of the ontology language used to model them.

As argued in Section 2.3.2, our ontology language of choice is WSML-Flight. Our approach allows to model business rules which result in inferring new knowledge, as well as to model constraint style business rules which would be verified against models. Therefore, WSML-Flight provides a formal basis as mentioned in require-ment (Req. 2) for capturing information related to process and application ontolo-gies in order to perform their formal analysis.

In the following sections we discuss the usage and advantages of the formalized business policies and rules in terms of assisting the process modeler by automating

the process of finding the relevant business policies for a given process model and their automated verification.