summary: A FORMAL ANALYSIS OF A BUSINESS CONTRACT LANGUAGE

G. Governatori and Z. Milosevic. A formal analysis of a business contract language. Int. J. Cooperative Inf. Syst., 15(4):659–685, 2006.

This paper presents a formal system for describing contracts in terms of deontic concepts such as obligations, permissions and prohibitions, and the logic supports reasoning about violations of obligations in contracts. Using a formal representation for contracts. The paper first provided a sample contract to be used as an example. The showed the importance of using formal languages to represent contracts. After that stated that a formal language intended to represent contracts should provide notions related to the concepts of obligations, permissions, and entitlements.

The paper explained the FCL rules anatomy (r : ¬p,¬α |- OSupplierβ) showing that every rule should start with a unique name/id (r), then a list of conditions (¬p,¬α ), that when true, a consequence (OSupplierβ) to be applied. It also showed that FCL could represent permission, obligation, prohibition, and negation. Another useful tool used by FCL is the ‘⊗-expression’ that can be used to repair violations. FCL can be used to analyse contracts and to reason about them so that ambiguities in a contract can be identified.

The paper then introduced a procedure that uses FCL to generate a formal (logical) form of the contract. First step to do so is to combine contract closes of obligations with the obligations that triggered in response to violations of these obligations. Second step is identifying and removing redundancies from the formal specifications, redundancy occur when the normative content of one rule (r2) are all included in another rule (r1), then we can easily say that r2 does not add anything and can be discarded. Final step is finding and solving the issue of conflicts by either creating a superiority relation over the rules (≺) and to use it do “defeat” the weaker rule, or by supplementing the antecedent of one rule with an additional guard.

The paper then gave an explanation about BCL (Business Contract Language). BCL is to enable monitoring of contract execution in an event-based manner. The main use of event patterns in BCL is to enable checking of policies related to a contract. Policies define behavioural constraints for the roles that carry out activities in a contract and these constraints are described in terms of event patterns. Policy checking consists of identifying event patterns in activities of parties filling a role and establishing whether they satisfy the policies. The policies take a form of modal constraints such as obligations, permissions and prohibitions. A policy violation can be linked to another policy that can take effect in response to this violation.

BCL uses the following attributes:

·      Role: to label a party whose behavior is constrained by the policy. 

·      Event patterns: where events can be matched with event patterns using event type. Checking policies consists of identifying event patterns in activates. Events in BCL can have event roles, which can be linked to contract roles.

·      State: used to define data value shared by participants. It is used to maintain running totals, counters, and other states.

·      Policy: it is associated with a role and indicate wither it is an obligation, permission, or prohibition. Policy consist of a name, the role that this policy applies to, what type of modality applies, what triggers this policy, and what is the expected behavior based on this policy. It might also include a Guard that specify a specific timing when will this policy should be applied. A guard can be used to specify that a policy only will occur in case of violation of another policy.

The authors stated that even thought there are other contract languages such as Contract Expression Language, Web Services Level Agreements and ecXML. BCL “covers broader aspects, including the organisational context for the definition of policies, behaviour and structure and relationships between these concepts”.

Finally the paper introduced a mapping from FCL to BCL, and then from BCL to FCL. To map FCL to BCL, the name/id of the rule in FCL can map to the policy name in BCL. The model literal in FCL rule gives the role, modality, and expected behavior of BCL policy. Finally the condition literals in FCL rule will map to trigger in BCL policy.  The same concept can be reversed to map from BCL to FCL.

The paper then stated that BCL need a better separation between subject and target roles, also a better separation between trigger event and the action event. Another shortcoming of BCL is the lack of priorities support between rules to avoid conflicts. BCL need to be tested against the notions of delegation and authorization.

Summary: An Algorithm for Business Process Compliance

G. Governatori and A. Rotolo. An algorithm for business process compliance. In E. Francesconi, G. Sartor, and D. Tiscornia, editors, JURIX, volume 189 of Frontiers in Artificial Intelligence and Applications, pages 186–191. IOS Press, 2008.

Business process compliance means the adherence or consistence of a set of specifications modelling a business process and a set of specifications modelling the norms for a particular business. Business process specifications describe how a process is executed, while norms state what can be done and what cannot be done by a process. Compliance checking is to figure out (a) which obligations will definitely appear when executing the process, and (b) which of those obligations may not be fulfilled. This paper introduces an algorithm that provides a compliance checking.

The paper first chooses FCL as the formal rules language, FCL (Formal Contract Language) is a logical language that represents rules as expressions. FCL uses the following operators ¬(negation), O (obligation), P (permission), and ⊗ (violation/reparation), ∼p denote the complement of p. (≺) determines the priorities between two rules to avoid conflicts. FCL expressions such as:

r1 : account(y) ⇒ OpositiveBalance(y) ⊗ OapproveManager(y)

Which means for account y it is an obligation to have a positive balance, if this obligation was violated then it is an obligation to get manager approval. After writing all rules in FCL, one can enrich the process model by these rules expressions.

Then the paper explains process models showing how to annotate them with these rules expressions. Finally, it presents the compliance-checking algorithm. To do compliance checking there are three steps to go through. Step one ‘building procedure’, consists of the following: 1- identifying sets of effects for each task from the process model. 2- determine the normative position (obligation, permission, prohibition) for each set of effects of these tasks. 3- for each task check if obligation is fulfilled or a violation has occurred. Step two ‘from tasks to obligations’, which determine the obligations derived by the tasks. Step three ‘checking compliance’, is applying the checkCompliance algorithm.

Governatori and Rotolo in this paper proposed a compliance algorithm, using FCL as the rule modeling language. FCL has the ability to represent obligation, permission, and negation. It also has the ability to show what to do incase of violation. And also uses a priority operator to avoid conflicts. FCL do not differentiate between different types of obligations (e.g. if an obligation is continues or occur once). Also it does not have the ability to represent time constrains regulations, or if an obligation need to happen after another obligation already happened and never before.

summary: Designing Compliant Business Processes with Obligations and Permissions

S. Goedertier and J. Vanthienen. Designing compliant business processes with obligations and permissions. In J. Eder and S. Dustdar, editors, Business Process Management Workshops, volume 4103 of Lecture Notes in Computer Science, pages 5–14. Springer, 2006.

This paper introduces a new language called PENELOPE (Process ENtailment from the ELicitation of Obligations and PErmissions), a language to express temporal rules about the obligations and permissions in a business interaction. It does not consider the execution time monitoring of business contracts, but rather considers the impact of sequence and timing constraints on business process design.

PENELOPE uses deontic properties to express rules and regulations. It distinguishes between necessity and possibility in business policy and regulations, by considering the deontic modalities of obligation, conditional commitment and permission. It does not consider prohibition, as it is assumed if neither permission nor obligation can be derived. It allows to explicitly define deadlines. The following are some PENELOPE’s properties:

Termination of a process means that no obligations or permissions exist. If there exist obligations or permissions and no permissible performance exist to carry the business interaction forward it is called a deadlocks situation. Where In a livelock situation, the protocol state is trapped in an infinite loop. Deontic conflicts arise when there are protocols state a business partner has both the permission and the prohibition to an activity. This type of conflict is not possible in PENELOPE, as it does not make use of prohibition. Temporal conflicts occur when two deontic assignments at the same time initiate and terminate a permission, obligation or conditional commitment. Trust conflict occur when a business interaction puts the business in a position were it has direct obligations towards non-trusted business partners that involve sensitive activities. The paper provided an algorithm if followed one could avoid all these conflicts and locks.

Goedertier and Vanthienen in this paper presented a new language called PENELOPE, which is based on deontic logic. It has the ability to represent obligation, conditional commitment and permission. It does not represent prohibition, as it is assumed in case no permission nor obligation was presented. The assumption of prohibition gave the ability to avoid conflicts. It does not provide what to do in case of violation, as the language is more concerned with design time than execution time.

Summary: A Methodological Framework for Aligning Business Processes and Regulatory Compliance

S. Sadiq and G. Governatori. A methodological framework for aligning business processes and regulatory compliance. In J. Brocke and M. Rosemann, editors, Handbook of business process management: 2 Strategic alignment, governance, people and culture, International Handbooks on Information Systems, pages 159–176, Berlin and Heidelberg, 2010. Springer-Verlag Berlin Heidelberg.

This chapter focuses on compliance by design. It starts different types of compliance (detective, corrective, and preventive), and show that the best way to have a preventive method is to integrate compliance from the design stage. It also shows that to be able to have compliance first it is important to have a formal representation of the rules and regulations, then need to find an alignment between the two ontology (business rules languages and process model language), then need to have a compliance enforcement framework, and finally, compliance monitoring.

The chapter then reviewed the literature on business rules modeling languages. It stated that (Governatori, 2005), and (Governatori & Milosevic, 2006) have proposed FCL (Formal Contract Language) as a candidate for control modelling, which has proved effective due to its ability to reason with violations. While (Goedertier & Vanthienen, 2006) presents a logical language PENELOPE that provides the ability to verify temporal constraints arising from compliance requirements on affected business processes. (Kuster, Ryndina & Gall, 2007) provide a method to check compliance between object lifecycles that provide reference models for data artifacts e.g. insurance claims and business process models. (Giblin, Muller & Pfitzmann, 2006) who provide temporal rule patterns for regulatory policies, although the objective of this work is to facilitate event monitoring rather than the usage of the patterns for support of design time activities. Furthermore, (Agrawal, Johnson, Kiernan & Leymann, 2006) has presented a workflow architecture for supporting Sarbanes-Oxley Internal Controls, which include functions such as workflow modeling, active enforcement, workflow auditing, as well as anomaly detection. Although several proposals provide a powerful and conceptually faithful means of capturing controls, it still remains to be studied, how these formal models can be deployed in practice.

As shown earlier in the chapter modeling rules is only one step toward compliance, for this reason the chapter then reviewed the literature on enforcing the rules model into the process model (enriching business process models). It stated that the work by (zur Muehlen & Rosemann, 2005) and (Neiger, Churilov, zur Muehlen & Rosemann, 2006) provides an appealing method for integrating risks in business processes. The proposed technique for “risk-aware” business process models is developed for EPCs (Event Process Chains) using an ex- tended notation. (Sadiq, Governatori & Namiri, 2007) propose an approach based on control tags to visualize internal controls on process models. (Liu, Muller & Xu, 2007) takes a similar approach of annotating and checking process models against compliance rules, although the visual rule language, namely BPSL is general purpose and does not directly address the notions representing compliance requirements.

The chapter then concluded by showing that a theoretically rigorous and practically feasible means of control modelling supported by a powerful analysis machinery that provides diagnostic support for comparing business and control objectives has the potential to create a holistic approach to compliance management, by not only providing preventative and detective techniques, but also corrective recommendations. Then indicated that future research in this area should strive towards compliance management frameworks that provide a close integration of the three perspectives namely preventative, detective and corrective. Such a framework can allow organizations to better respond to the changing regulatory demands and also reap the benefits of process improvement.

Sadiq and Governatori in this chapter provided a holistic overview over the ‘business process compliance’ topic. The chapter showed different types of compliance (detective, corrective, and preventive), and showed that compliance by design is the best way to have a preventive compliance method. The authors emphasized at the importance of having formal representations of business rules and then enriching the business process models with compliance requirements. The chapter then provided a literature review for both aspects. The chapter concluded with a discussion showing that a rigorous and feasible formal representation of the business rules that can be used to enrich a business process model and provides a diagnostic support, can potentially provide a holistic approach to compliance management. 

Summary: Modeling languages for business processes and business rules: A representational analysis

M. zur Muehlen and M. Indulska. Modeling languages for business processes and business rules: A representational analysis. Information Systems, 35(4):379–390, Elsevier, 2010.

Process modeling languages and rules modeling languages are both used to document organizational policies and procedures. While process modeling languages typically describe a procedural sequence of activities, including decisions and concurrency, rules modeling languages often rely on a declarative description of conditions, and constraints that need to be followed. Understanding the relationship between the two languages types would allow organizations to maximize synergies, avoid content duplication, and thus reduce their overall modeling effort. Rules modeling languages has received less attention than process modeling languages. This paper is to investigate the capabilities of four rule modeling languages, namely: Simple Rule Markup Language (SRML), Semantic Web Rules Language (SWRL), Production Rule Representation (PRR), and Semantics of Business Vocabulary and Business Rules (SBVR). The paper looks into the representational capabilities of these languages, and if these capabilities are complementary or substitutive to those of process modeling languages. The paper also looked into integration with respect to four process modeling languages: Colored Petri nets (CPN), Event-driven Process Chains (EPC), Integrated DEFinition methodology (IDEF), and Business Process Modeling Notation (BPMN).

Business rules can be categorized into 5 different types: Integrity rules (the acceptable relationship between elements), Derivation rules (used to infer new facts based on known facts), Reaction rules (alternative action rules), Production rules (condition, action rules), and Transformation rules (restrict the state of changes). Process modeling languages can be: Activity centric, Process object centric, and Resource centric. Process languages appear as “graph-based languages (e.g. BPMN, EPC), net-based languages (e.g. Petri nets, flow nets), and workflow programming languages (e.g. Business Process Execution Language (BPEL))”. Work on integration of these two types of languages appeared after introducing rule modeling concept, but no theory-based evaluation of the usefulness of these combinations has been conducted so far. There is a need to augment existing research on the representational capabilities of process modeling languages with matching evaluations on the rule modeling side. Furthermore, there is a need to provide practitioners with guidance as to which rule modeling language and which combination of rule and process modeling languages will allow them to capture the most real-world details using language primitives.

The authors used Bunge-Wand-Weber (BWW) ontology to develop criteria construct. Based on these criteria the study showed that in general SRML would satisfy more constructs than other rule modeling language. Moreover, in combination with a process modeling language it was shown that the combination of SRML and BPMN would provide the best representation capability, thus the best combination of the eight examined languages.  The study then went a step further considering combining rule modeling language with rule specification beside the process modeling language. The paper considered two combinations SBVR with PRR and SBVR with SWRL, then compared these two combination in respect to all four process modeling languages. The study shows that Even thought the pare SBVR with PRR is a strong combination with BPMN than any other pare, but it is still better to use SRML with BPMN as it has better representation capabilities.

Zur Muehlen and Indulska in this paper compared between four ‘rule modeling languages’ (SRML, SWRL, PRR, and SBVR) in respect to integration with four different process modeling languages (CPN, EPC, IDEF, and BPMN) based on representation capabilities criteria. The study showed that the best combination is to have SRML as the rule language and combine it with BPMN as a process modeling language; this combination satisfies more representation capabilities than any other combination. The study was limited to only four rule languages and four process modeling languages (non of which is an automation language). And the study was also limited to comparing in regard to representation capabilities. So based on this study, if representation capability was the important aspect one is looking for, and the choice was between these four rule languages and these four process modeling languages, one showed chose SRML and BPMN.

L.R. on Integration of business rules and business processes

M. zur Muehlen and M. Indulska. Modeling languages for business processes and business rules: A representational analysis. Information Systems, 35(4):379–390, Elsevier, 2010.

Early work on the integration of business rules and business processes appeared shortly after the introduction of the rule modeling concept [13,14]. Krogstie et al. [16] were the first to suggest that business process and rule modeling approaches should be merged to improve the capture of temporal information for Information Systems (IS) development. They presented a top-down approach for model specification that involves the use of the External Rule Language for specification of process logic at the lowest level of decomposition. McBrien and Seltveit [20] further enhanced this concept by defining the structure of rules within the process model. Knolmayer et al. [14] refined process modeling and linked the resulting models to workflow execution through layers of Reaction Business Rules. Kappel et al. [13] use Reaction
Business Rules to model the coordination in workflow systems. Kovacic [15] developed a meta-model that represents important business constructs (goal, process, activity and events) and technical constructs (data objects, software components, actions in Information Systems). He demonstrates how rules can link these two categories of constructs. Charfi and Mezini [1] argues that business rules are often hard-coded into web services and proposes a hybrid approach of separating business processes and business rules. Meng et al. [21] introduced a dynamic workflow management system for modeling and control- ling the execution of inter-organizational business pro- cesses. The system uses an event- and rule-server to trigger business rules during the enactment of workflow processes in order to enforce business constraints and policies.
While the integration of rule and process modeling has been the subject of some investigation in the research community, anecdotal evidence shows that organizations struggle to effectively capture business processes and rules. In a recent study of the representational capabilities of the Business Process Modeling Notation (BPMN), we found that organizations frequently supplement their BPMN process models with textual annotations of busi- ness rules [27]. This practice introduces problems regard- ing the consistency, reuse, and enforcement of rules – problems that are acknowledged by some of the organiza- tions using this technique.
The need to improve the representation of business rules within process model diagrams is apparent, yet little is known about which representation aspects, if any, are unique to each of the two types of modeling languages. Previous work by Recker et al. [26] has identified a general lack among process modeling languages to adequately represent business rules. Similarly, Green and Rosemann [6] found limitations with respect to modeling business rules in their BWW-based investigation of all five views of Architecture of Integrated Information Systems a popular enterprise architecture framework.
Rule modeling languages are likely candidates to fill such gaps. An earlier study by Herbst et al. [9] suggests that rule specification languages should be considered as a potential addition to graphical representation languages when modeling for Information Systems design. While their analysis is not based on any formal framework, they suggest that many of the popular IS modeling techniques lack the ability to adequately represent business rules. The work of Rosemann et al. [29] suggests that the same shortcomings exist in the process modeling domain; hence, an integration of business rule and business process modeling approaches may help overcome these perceived shortcomings.
In order to effectively integrate graphical business process modeling approaches with business rule model- ing approaches, we need to understand their synergies and overlap. In our research, we were unable to locate any attempts to evaluate the expressiveness of rule modeling languages or their relationships to conceptual process modeling approaches. The only related work appears to be that of Lu and Sadiq [17] who compared graph-based and rule-based modeling approaches. Since their work was focused on workflow modeling in particular, rather than conceptual modeling in general, no specific rule modeling languages were considered. The authors used a set of workflow patterns [36] as a basis for the evaluation, and found, that rule- and graph-based modeling approaches had similar levels of expressiveness in terms of the control flows specified by the workflow patterns.

1   : A. Charfi, M. Mezini, Hybrid web service composition: business pro- cesses meet business rules, in: Paper presented at the Proceedings of the Second International Conference on Service Oriented Computing, New York, NY, USA, 2004.
6   : P. Green, M. Rosemann, Perceived ontological weaknesses of process modelling techniques: further evidence, in: Paper presented at the 10th European Conference on Information Systems, Gdansk, 2002.
9   : H. Herbst, G. Knolmayer, T. Myrach, M. Schlesinger, The specifica- tion of business rules: a comparison of selected methodologies, in: A.A. Verijn-Stuart, T.-W. Olle (Eds.), Methods and Associated Tools for the Information System Life Cycle, Elsevier, Amsterdam, 1994, pp. 29–46.
13 : G. Kappel, S. Rausch-Schott, W. Retschitzegger, Coordination in workflow management systems – a rule-based approach, in: W. Conen, G. Neumann (Eds.), Coordination Technology for Collabora-
tive Applications – Organizations, Processes, and Agents, 1364 ed., vol. 1364, Springer, Berlin, 1998, pp. 99–119.
14 : G.F. Knolmayer, R. Endl, M. Pfahrer, Modeling processes and
workflows by business rules, in: W.M.P. van der Aalst, J. Desel, A. Oberweis (Eds.), Business Process Management, Models, Techni- ques, and Empirical Studies, vol. 1806, Springer, London, 2000, pp. 16–29.

15 : A. Kovacic, Business renovation: business rules (still) the missing link, Business Process Management Journal 10 (2) (2004) 158.

16 : J. Krogstie, P. McBrien, R. Owens, A.H. Seltveit, Information systems development using a combination of process and rule-based approaches, in: R. Andersen, J.A. Bubenko Jr., A. Solvberg (Eds.), Third International Conference on Advanced Information Systems Engineering (CAiSE ‘91), Springer, Trondheim, Norway, 1991, pp. 319–335.

17 : R. Lu, S. Sadiq, A survey of comparative business process modeling approaches, in: Paper presented at the Proceedings of the 10th International Conference on Business Information Systems, Poznan, Poland, 2007.
20 : P. Mcbrien, A.H. Seltveit, Coupling process models and business rules, in: Proceedings of the IFIP 8.1 WG Conference on Information Systems Development for Decentralized Organizations, 1995.
21 : J. Meng, S.Y.W. Su, H. Lam, A. Helal, Achieving dynamic inter- organizational workflow management by integrating business processes, events and rules, in: Paper presented at the Proceedings of the 35th Annual Hawaii International Conference on System Sciences System Sciences, HICSS 2002, Waikoloa, HI, 2002.
26 : J. Recker, M. Indulska, M. Rosemann, P. Green, Do process modelling techniques get better? A comparative ontological analysis of BPMN, in: Paper presented at the Proceedings of the 16th Australasian Conference on Information Systems, Sydney, Australia, 2005.
27 : J. Recker, M. Indulska, M. Rosemann, P. Green, How good is BPMN really? Insights from theory and practice, in: Paper presented at the 14th European Conference on Information Systems, Goeteborg, Sweden, 2006.
29 : M. Rosemann, J. Recker, M. Indulska, P. Green, A study of the evolution of the representational capabilities of process modeling grammars, in: E. Dubois, K. Pohl (Eds.), Advanced Information Systems Engineering – CAiSE 2006, vol. 4001, Springer, Luxem- bourg, Grand-Duchy of Luxembourg, 2006, pp. 447–461.
36 : W.M.P. Van Der Aalst, A.H.M. Ter Hofstede, B. Kiepuszewski, A.P. Barros, Workflow patterns, Distributed and Parallel Databases 14 (1) (2003) 5–51.

Types of business rules

M. zur Muehlen and M. Indulska. Modeling languages for business processes and business rules: A representational analysis. Information Systems, 35(4):379–390, Elsevier, 2010.

Different types of business rules can be distinguished:

• Integrity rules express constraints. These rules typically define the acceptable relationship between data ele- ments. For example, each project must have one and only one project manager.
• Derivation rules express conditions that result in conclusions. These rules define the validity of facts and can be used to infer new facts based on known facts. For example, platinum customers receive a 5% discount. John Doe is a platinum customer. As a conclusion, John Doe receives a 5% discount.
• Reaction rules (also known as Event-Condition- Action (ECA) rules, alternative-action rules, or post- conditions) specify a trigger that activates the evaluation of the rule, a condition that is evaluated, and a subsequent activity that will be carried out if the specified condition is met; for example, the evaluation of a reaction rule is triggered as soon as a new invoice is received. If the invoice amount is more than $1000 then a supervisor review is initiated.
• Production rules (also known as condition, action rules) are similar to reaction rules, but do not specify a particular circumstance in which the evalua- tion takes place; For example, if there are no defects in the last 10 widgets, the entire batch is quality approved.
• Transformation rules restrict the state changes of objects; for example, an employee’s age can change from 30 to 31, but not from 31 to 30.

G. Wagner, Rule modeling and markup, in: N. Eisinger, J. Maluszynski (Eds.), Reasoning Web, 3564 ed., vol. 3564, Springer, Berlin, Msida, Malta, 2005, pp. 251–274.