الگوریتم های برای تجزیه و تحلیل های مربوط به قوانین کسب و کار محدودیت

Constraints represent a class of business rules that describe the conditions under which an organisation operates. It is common that organisations implement a large number of constraints in their supporting information systems. To remain competitive in today's ever-changing business environment, organisations are increasingly recognising the ability to evolve the implemented constraints timely and correctly. While many techniques have been proposed to assist constraint specification and enforcement in information systems, little has been done so far to help constraint evolution. In this paper, we introduce a form of constraint analysis that is particularly geared towards constraint evolution. More specifically, we propose several algorithms for determining which constraints collectively restrict a specified set of business objects, and we study their performance. Since the constraints contained in an information system are typically in large quantities and tend to be fragmented during implementation, this type of analysis is desirable and valuable in the process of their evolution.

Constraints are commonly employed in information systems to ensure that the data stored and produced by the systems are valid and represent the intended semantics of the real-world [15], [17] and [25]. Such constraints are typically derived from business requirements, and therefore can be thought of representing a class of business rules that describe the conditions under which an organisation operates [18] and [26]. For example, one constraint might define the criteria that make a customer eligible for a certain kind of discount, which corresponds closely to the organisation's policy on customer discount. Constraints are typically very volatile, perhaps due to their business origin. New restrictions are frequently imposed on organisations as a result of changes to statutory regulations, government policy and economic/market conditions. Many organisations also choose to modify their business rules on an on-going basis, in order to remain competitive in today's ever-changing business environment. These changes frequently trigger the need to update the constraints implemented in the supporting information systems. However, updating an implemented set of constraints is not easy. Typically, a constraint begins its life as a high-level (natural language) statement of some condition or policy that the organisation wishes to enforce, and then gets fragmented and dispersed throughout the system in its implementation. For example, a constraint might state that all customers whose total business within the last year is greater than £5000 are eligible for a 5% discount on all orders. The code relating to its implementation might need to be inserted into application programs and the database management system which manage: the creation of new customer orders; modification of existing orders, maintenance of information on current discounts; and archiving of historical customer data. If the mapping from the high-level constraint statement to the software artefacts was accurately documented and maintained, then it would not be very difficult to update this constraint. Unfortunately, many constraints are introduced into an information system as and when they are needed. Even today, constraints are rarely documented comprehensively during system development and any document that is created quickly becomes out of date and unreliable. Therefore, system engineers are often forced to sift through the entire system in order to identify the constraints that are affected by a change made at the high level. This is undesirable because • First, an information system typically implements a large number of constraints. For example, Herbst et al. reported the existence of 627 business rules in a 12,000 line COBOL application [19], and a similar result was shown in [10], where 809 business rules were found in a 30,000 line COBOL code. Many of these rules are constraints. The large number of constraints makes it a very time-consuming process for the system engineer to manually identify the subset of constraints that is actually relevant to the task in hand. • Second, without an accurate knowledge of how the statement is mapped to the corresponding software artefacts, trying to determine manually which implemented constraints are affected by the change made to the high-level statement during evolution becomes a rather error-prone process, particularly when the set of implemented constraints is large. Thus, there is a need for techniques which can help system engineers to locate and piece together the relevant constraints at a higher level automatically. While many theories and techniques have been proposed to assist constraint specification and enforcement in information systems, little has been done so far to help their evolution. In this paper, we introduce a form of constraint analysis that supports constraint evolution. More specifically, we assume that the set of constraints implemented in an information system has already been identified or recovered, either from available documentation, domain experts or through reverse engineering [10] and [12], and we propose several algorithms for determining which subset of the constraints collectively restricts the state of a specified set of business objects. This is based on our observation that the majority of constraints are defined in terms of business concepts or objects. For example, our example constraint on customer discount is stated in terms of business concepts such as customer, discount and order. Thus, by using business objects as “glue”, we can help the system engineer to locate a coherent set of constraints that is relevant to the evolution task in hand. The paper is organised as follows. Section 2 introduces some basic concepts and notations used in the paper. The algorithms for determining which constraints collectively restrict a specified set of business objects are given in Section 3. In Section 4 we study the performance of the proposed algorithms. We show that our algorithms have a polynomial complexity and therefore can scale to non-trivial applications. Conclusions and future work are given in Section 5.

In this paper, we introduced a form of analysis that can be used to determine which set of constraints is related to a specified set of business objects. This form of analysis is important and useful in constraint evolution––it helps system engineers to identify, from the many implemented in an information system, a coherent subset of constraints that must be examined and updated in order to implement a change made to the high-level policy statements or business rules. It also helps system designers and business users to comprehend how constraint business rules are actually implemented and enforced in the supporting information systems. So far, there has been little work on developing techniques to support this type of constraint analysis. In this paper, we proposed three algorithms for identifying constraints that are directly, indirectly and implicitly related to a specified set of business objects. Both theoretic analysis and experimental results show that the proposed algorithms are efficient and have a performance that can scale to non-trivial applications. There are a number of issues that we plan to investigate in future. First, while this paper is focused on analysing the relatedness property for constraints, there are other properties that constraints may have and identifying them can be beneficial to both constraint evolution and comprehension. For example, for a given group of business objects, we may wish to determine whether there exists a conflict among the constraints that constrain them. This sort of analysis is useful when we wish to check if we have updated the set of constraints correctly for the set of business objects concerned. Second, in order to help system engineers in the task of evolving constraint business rules, it is desirable to present the constraints identified by our algorithms to the user as human comprehensible business rules. This requires (1) an ontological mapping from the system-oriented terms used in the implemented constraint to those preferred by the user in the business context; and (2) the ability to assemble several implemented constraints into a single, high-level constraint statement. Both are non-trivial and require substantial research effort.