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.

summary: Law, Logic and Business Processes

G. Governatori. Law, logic and business processes. In Requirements Engineering and Law (RELAW), 2010 Third International Workshop on, pages 1 –10, sept. 2010.

Compliance is a relationship between two sets of specifications, business processes and regulations. To be able to determine the compliance one needs to have: a formal representation of the business process, a formal representation of the regulations, and a common framework to interface the two formal languages. Enterprises are more dependent on PAIS (process aware information systems), and business processes are increasingly constrained by the legislative and regulatory framework in which they operate. Research should “address the issue of how to incorporate techniques to handle normative requirements, and these techniques should be conceptual, in the sense that they should provide notions and construction as close as possible to the concepts they intend to models”.

The author believes that there are three important features to be able to model compliance, which are defeasibility, the deontic effect of a norm, and whether the effects of a norm are persistent. “Defeasibility, the notion that a conclusion can be withdrawn, in case of additional information that allow to conclude the opposite, is very important in modelling normative reasoning where we can combine different sources for norms. This is particularly suitable for processes, where we can derive plausible conclusion based on the information provided, but when more data becomes available the conclusion can be changed. The deontic effects (obligations, permissions, prohibitions) are essential to capture compliance. They specify what is permitted, forbidden and required to fulfill the normative requirements. Finally the features about the persistency of normative effects allow us to define different types of obligations, with different conditions for their fulfillment of violation. These features have the effect that we are able to model different types of common scenarios”.

The paper proposed a new language “Process Compliance Language (PCL)” based on enhancing an older solution FCL (formal contract language) from another paper (“An algorithm for business process compliance”), it generalizes and extend FCL. First it distinguishes between achievement obligation (happen at least once before deadline) and maintenance obligation (continues). It also shows that achievement obligations can be persistent (must happen even after deadline) or non-persistent (once the deadline occur the obligation no longer holds). Also achievement obligations can be preemptive (can happen before the trigger) or non-preemptive (must only happen after the trigger). PCL provides a way of writing regulations that if an obligation was violated the rule will show what to do next it uses the non-boolean connective ‘⊗’ to link the obligation to another obligation that would be enforced if the first one was violated (e.g. Oa,π A ⊗ OpB ⊗ OmC means that the primary provision is an achievement, persistent, obligation to do A, but if A is not done, then we have a punctual obligation to do B. If B fails to be realised, then we obtain a maintenance obligation to do C). The language also provides superiority relation (≺) determines the relative strength of two rules, to solve potential conflicts. The process to build the rules model in PCL is: 1- write regulations using the formal language represented in here, 2- remove any redundant rules, 3- label and detect conflicts.

The paper then explained business process models and it main components, and gave an example process from the banking field and showed it process model and how to write the related rules using PCL. Then finally gave a procedure to check wither execution paths of a process are compliant with the PCL and thus with the normative system modeled by the PCL specifications. The procedure is: first identify set of effects for all the tasks in the process. Second, for each task determine the normative position (obligations, permissions, prohibitions). Finally, for each task compare the effects of the tasks and the obligations accumulated up to the task. If an obligation is fulfilled by a task, discharge the obligation, if it is violated signals this violation. If it is not fulfilled nor violated, keep the obligation in the stack of obligations and propagate the obligation to the successive tasks.

Governatori in this paper presented a new language PCL, which can be used to write regulations and rules. The language has the ability to show different types of obligations and also handle violations. The language can also be used to avoid conflict if they were detected in the writing stage, using the consistent writing process. The paper only showed how this language can handle rules that say what must be done, but do not have the ability to follow a rule that say how to do it (the author claim that the language has the ability and will be explained in another paper). The paper also provided an algorithm that detects compliance between a business process and regulations written in PCL. Although PCL can handle various types of obligations it did not show how to handle permissions and prohibitions.

why we need to integrate security in BPM

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 security policies 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, security policy languages often rely on a declarative description of security conditions, and constraints that need to be followed. To date, their synergies and overlap are under researched. Understanding the relationship between the two languages types would allow organizations to maximize synergies, avoid content duplication, and thus reduce their overall effort.

G. Governatori. Law, logic and business processes. In Requirements Engineering and Law (RELAW), 2010 Third International Workshop on, pages 1 –10, sept. 2010.

S. Sadiq and G. Governatori, “Managing regulatory compliance in business processes,” in Handbook of Business Process Management, J. van Brocke and M. Rosemann, Eds.    Berlin: Springer, 2010, vol. 2, ch. 8, pp. 157–173.


Nowadays more and more businesses in all sectors relay and heavily depends on their process aware information systems. These systems are now essential to control, administer and enact all core business activities. Furthermore, failure to follow security policies is no longer an option. This means that research in business processes must now address the issue of how to incorporate techniques to handle security policies requirements, and these techniques should be conceptual, in the sense that they should provide notions and construction as close as possible to the concepts they intend to models. Until now ad-hoc solutions appear as the only option for otherwise routine situations. This leads to increased cost, and this is one of the reasons why security policies are still seen as burden on a process, instead of an opportunity to improve the performance of it.

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.

Business process languages such as UML Activity Diagrams, BPMN, Event- Process-Chains, etc. are most often based on the control-flow paradigm, and define an explicit order relation between the activities in the process. These order relations even occur in the case handling paradigm, in which a preferred or normal control-flow is defined between activities. What is lacking is a declarative approach that makes the partial order relations due to security and legal requirements more explicit.

what we need to enforce Sec. into BPM

G. Governatori. Law, logic and business processes. In Requirements Engineering and Law (RELAW), 2010 Third International Workshop on, pages 1 –10, sept. 2010.

It is a relationship between two set of specifications, where one the target does not result in violation of the source. This means that to determine whether a business process is appling the relevant security policies, one has to have:
1) a formal specification of the business process;
2) a formal specification of the (relevant) security policies;
3) a common framework to interface the two sets of specifications.
 

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

A formal language for security policies should be conceptual, allowing its users to focus exclusively on aspects related to the content of the policy, ignoring implementation aspects.

Summary: Framework for Business Process and Rule Integration: A Case of BPMN and SBVR

R. Cheng, S. W. Sadiq, and M. Indulska. Framework for business process and rule integration: A case of bpmn and sbvr. In W. Abramowicz, editor, BIS, volume 87 of Lecture Notes in Business Information Processing, pages 13–24. Springer, 2011.

“Integrating the outputs of the two modeling approaches is a challenging task. First, business process models tend to be visual in nature. Business rules, however, tend to be text-oriented. Second, they have different composing elements. Third, they are designed for different purposes - process models describe how things should happen, whereas business rules describe what should happen. Finally, the overlap and inconsistencies between business process models and business rules also presents a significant challenge”. This paper is about a framework that integrates BPMN (Business Process Modeling Notation 2.0), process modeling language, and SBVR (Semantics of Business Vocabulary and Business Rules), rules modeling language.

Most available frameworks follow a top-down approach, and that integration should happen in the design stage, which is correct but not realistic. As in reality most organisations already have existing processes’ models and rules’ models that are separate, and the real problem facing organisations is integrating these existing models. That’s why a bottom-up approach is required, where integration happens in analysis stage. “The bottom-up integration framework is built around a collection of mapping methods that provide distinct ways in which overlap and consistency (or lack of) between processes and rules can be studied”.

Integration framework have two main aspects; semantic and structural aspects. Semantics aspects are about providing a reference that can provide a mapping between the two languages terms. Structural aspects are dealing with how the two languages have different structures. This paper only looked into structural aspects.

XML Process Definition Language (XPDL) was used as a canonical intermediate language to bridge the gap between BPMN, a visual process modeling approach, and SBVR, a text based business rule’s modeling language. Because, it is standardized and well supported, also it has the ability to transfer BPMN graphical notations into text representation.

To provide a mapping, both languages have to be broken down to the main components. SBVR was brought down to Name, Term, Verb, and four types of keywords. While BPMN consist of: activities, events, gateways, and participants. XPDL is used to translate each one of these BPMN components into XPDL tags and then mapped into SBVR component (a table is provided in the paper). The proposed approach do not have a way to present the model operation in BPMN except using ‘must’ or ‘it is obligatory’, which is considered a limitation of the solution. The paper also provided a car sale process and its business rules to demonstrate the proposed solution and prove its effectiveness.

in L.R.:

Cheng et al. in provided a bottom-up approach to integrate process models and business rules models in an analysis stage. There approach was specific to integrating BPMN process models with SBVR rules models. It used XPDL to translate the BPMN diagrams to text representation and then used these tags to map the business rules models, and finally producing a new model that include both the process and the rules. Even thought the approach was applied to BPMN and SBVR, but the idea can be generalized to other languages. A limitation to the approach, that it was only able to represent BPMN operations using either ‘must’ or ‘it is obligatory’. The approach did not invent a new language. It made use of XPDL and its ability to translate BPMN diagrams into XML tags. The main contribution was providing a list of the main components of the process language (BPMN) and the rules language (SBVR), and using XPDL to map these components to each other.

Challenges in integrating BP models and regulations

 

R. Cheng, S. W. Sadiq, and M. Indulska. Framework for business process and rule integration: A case of bpmn and sbvr. In W. Abramowicz, editor, BIS, volume 87 of Lecture Notes in Business Information Processing, pages 13–24. Springer, 2011.

"Integrating the outputs of the two modeling approaches is a challenging task. First, business process models tend to be visual in nature, with most of the relevant information represented graphically. Business rules, however, tend to be text-oriented. Thus, integration of the outputs of the two approaches requires an information exchange format with minimal information loss. Second, process models differ from business rules fundamentally as they have different composing elements. Third, they are designed for different purposes - process models describe how things should happen, whereas business rules describe what should happen. Finally, the overlap and inconsistencies between business process models and business rules also presents a significant challenge. In particular, a set of criteria is required that helps a business analyst to resolve identified overlaps and inconsistencies in a satisfactory manner."