1. Introduction
Business rules are statements about the enterprise’s way of doing business. They reflect business policies. Organizations have policies in order to: satisfy the business objectives, satisfy customers, make good use of resources, and conform to laws or general business conventions [1]. Business rules become requirements, that is, they may be implemented in a software system as means of requirements of this software system [2]. But business rules tend to change over time due to new policies, new business realities, and new laws and regulations, for these reasons several approaches and technologies are created to separate business rules implementation from core modules. In all these approaches and technologies it is necessary explicitly connect business rules with core functionality.
The code that connects or links the business rules with core functionality is spread across core modules. We have named this code as connection code. A change in the rule specification requires changes in all modules where connection is present. These modifications are invasive and time-consuming. Further, because business rules are a lot more volatile compared to core business logic, mixing them together causes the core system to become just as volatile. For these reasons, AOP [3] is suitable when providing mechanisms that allow to connect or to integrate the business rules to the core modules without altering these components. Just as it is stated in [4], AOP facilitates the constant evolution of this type of concerns.
Aspectual connection that compose business rule, refers to the code in charge of not only triggering the application of the rules at certain events, but also gathering the necessary information for their application and incorporating their results in the rest of the core application functionality. The aspectual connection must meet some requirements for the business rule to be triggered. We have identified in [5] that the development (design and implementation) of connections with aspects is not a trivial work, and they are needful strategies to manage some shortcomings, as when the same business rule could require different connections in different domains; or when the business rules require the connections to adapt or change the domain; or when an interaction between excluded business rules is detected. These situations and other require specific strategy to analysis aspectual connections in previous steps of implementation stage. Some contributions show how connections could be implemented with aspects and with different AOP-tools [6-9]. The authors analyses the scheme of design and implementation with different goals but they only cover common and ordinary scenarios.
Therefore, this work outlines an approach to connect business rule with aspect. This approach considers the identification, analysis and construction of connections with aspects, (aspectual connection). We use our experience and previous works to define the initial steps, and complete them with the analysis of interactions and propose methods to implement aspectual connections code. Unlike to other works in this line, we address the interactions of aspectual connections and propose a method that it is thought to accept different design and implementation strategies with different aspect-oriented languages. Also we have developed a tool that gives complete support to the approach.
The outline of this paper is as follows: Section 2 will expose Business Rules main concepts; Section 3 will present the approach to connect business rule with aspects, with a brief description of main concepts of the approach; Section 4 will unfold the handling of interactions proposed; Section 5 will present the method to construct aspect connection code; Section 6 will present the MACS tool that supports this approach; Section 7 related works are presented and Section 8 we will give our conclusions.
2. Business Rules
Business rules are statements about the enterprises way of doing Business [10]. Organizations have policies in order to: satisfy the business objectives, satisfy customers, make good use of resources, and conform to laws or general business conventions. The business rule model distinguishes between functional rules and non-Functional rules. Functional rules are general policies regarding the organization functionality. Macrosystem rules describe policies that constrain the behavior and structure of the organization. Quality rules are demands of the organization on the characteristics of its processes or products. They usually reflect general policies related to quality standards or expectations of the organization. Other classical classifications of business rules are proposed [11-13]. Two approaches and technologies to implement business rules explicitly and separately from core functionality of applications are: Object Oriented Patterns, using patterns, such as the Rule Object Pattern [14] and Hybrid Systems, which support explicit and separate representation of rules in a rule-based language. An example is JESS [15].
However, the code which connects core functionality with business rules is tangled and scattered in core modules, for this reason is considered a crosscutting concern. Therefore, conventional approaches, as Object-Oriented Paradigm, are not able or enough to avoid this kind of problem. On the other hand, the business rules are very volatile as they change very frequently, and thus the volatility is spread to the core, where the connections are explicit.
3. An Approach to Connect Business Rule with Aspects
As aforementioned, in our previous works we have presented some preview of this approach: taxonomy to classify the aspectual connections, a template to document aspectual connections (ACT) [5] and a mapping process to generate automatically aspects [16]. After these experiences we integrate these contributions to propose an approach to connect business rule with aspects, systematically. The main features and strengths of this approach are:
1) It can be applied in different stages of development. For example it can be applied during advanced design when domain has been modeled or after the installation of application, during maintenance stage.
2) It is valid for any type of business rules. For example it can be used it to derivation, structural assertion or action assertion [17] business rules.
3) It is independent of base-programming language and aspect-oriented language.
4) It is lithe as it does not require another additional o specific artifact (for example diagrams of UML), it is oriented to obtaining real code instead of obtaining documentation and it consists of few steps. The approach is addressed to software applications were core modules and business rules are represented with traditional unit as classes, from Object Oriented paradigm. We mention this because of we have not had experiences with other techniques, such as hybrid systems.
The approach consists of three steps: definition, analysis and construction.
1) Definition of connections is the activity which specifies the required elements of connections in ACT and classifies them according the taxonomy of aspectual connections.
2) Analysis is the activity that detects interactions among connections and tried to find resolutions of them.
3) Construction is the activity that generates the aspect connection code. This task is the only one which is dependent of AOP-tool. However it could be adapted to different AOP-tools.
The approach is based on two main pillars: taxonomy of connection and a template to register and document elements of connections.
3.1. Taxonomy of Aspectual Connections
Aspectual connection that compose business rule, refers to the code in charge of not only triggering the application of the rules at certain events, but also gathering the necessary information for their application and incorporating their results in the rest of the core application functionality. The aspectual connection must meet some requirements for the business rule to be triggered. Here it is important to stress that a particular business rule could require different aspectual connections in different applications or even in the same application if it must be triggered by different events. Then, according to the imposed domain constrains, we can clearly identify four categories of aspectual connections: basic, query, change and complex.
Basic aspectual connection: the connection triggers the business rule in a specific point of the core functionality (event) the required information by the business rule is either available in the event context or it is global system information. The basic connection description needs the following elements: 1) Business rule elements, such as the class and method that encapsulates the business rule, the required information by the business rule and the business rule return. 2) Event elements, such as the domain class and method that represent the event that triggers the business rule, an indicator of when (before/ after/around) the business rule should be applied regarding the event execution.
Query aspectual connection: the connection triggers the business rule in a specific point of the core functionality but the information required by the business rule is not available in the event context. Then connection must first retrieve the information in order for it to be available when the business rule is applied. In this case, the aspectual connection should manage two events (pointcuts) and two advices, each one with different purposes. The query connection description needs the same elements of basic connections, and also the event (class and method name) where no contextual information should be retrieved plus the data type.
Change aspectual connection: the connection should add new properties (fields/methods) to the core functionality components in order for the business rule to be triggered. It means that the new business rule requires adapting the domain vocabulary. Then, the connection must support the domain adaptation such as the addition of new fields and methods in existing classes. The change connection description includes the same elements as basic connections and the description of the properties that should be added, such as new methods and fields.
Complex aspectual connection: this connection has the same characteristics of query and change connections. The connection has to update the domain for new business rules to be applied, but the needed information for the business rule condition is not available in the event context that triggers the business rule. This connection has the same elements that basic, query and change connections.
This taxonomy is independent of AOP language or base language. It only depends on the domain design and implementation and the requirements of new business rules.
3.2. Aspectual Connection Templates (ACT)
ACT is a simple artifact to identify, register and document the complete connection. In other words, all elements required by the connection could be detailed in ACT. ACT is composed of 7 sections (Figure 1). Section A identifies the connection. Section B identifies the business rule that would be triggered by the connection, class and method that encapsulates it. Section C identifies the event that triggers the business rule and when the business rule should be triggered (after/before/around). Section D must be completed when the information required by the business rule is not available in the event context that triggers the business rule, then in this section identifies the event where information must be retrieved. Section E must be completed when business rule requires domain adaptations. Section F identifies the interactions with other connections and the order in which they must be executed. And the last section classifies the connection according to taxonomy decrypted previously.
ACT category is basic if the only completed sections are A, B and C; it is query if Section D is also completed; it is change if Section E is also completed; and it is complex when all sections are completed. Hence Sections A, B and C are mandatory. Section F is completed during step 2 of the approach.
4. Interactions among Aspectual Connections
Aspect interactions, also known as conflicts or interferences, have been the subjects of extensive research with in AO community over the last years. An interaction arises when several aspects need to be executed at the same join point. This problem specifically, occurs when “the behavior of one aspect is affected by the behavior of another aspect”, so some interactions are negative and other interactions are inoffensive. The problem can be boarded from early development stages, but the real solution is absolutely constrained by the capacities and mechanism
Figure 1. Aspectual connection template (ACT).
of aspect oriented language used in the implementation of connection with aspects. Even, most approaches provide primitive support by letting the programmer specify the order of aspect execution. AspectJ [18] defines the declare precedence construct to specify the order of aspects. Strategies more flexible still are not supported by the popular tools. Even so, it is an advantage to know the potential interactions in aspect-oriented application in advance. Particularly in this sense, we have noted that, semantically, it is not the same an interaction between logging and profile aspects, than an interaction between aspects that connects two business rules of discount.
In the context of business rules, where connections are implemented with aspects, an interaction could happen when two or more business rules are triggered by the same event.
4.1. Identification of Shared Events
The taxonomy of aspectual connections and ACT can serve to analyses the interaction among connections. Actually it is possible to anticipate which type of interactions can happen and what events are affected by them. Suppose that C#1 and C#2 connections are documented in two ACT, the potential interactions are described in Table 1. The third column indicates what events (of ACT) should present an interaction.
In this way, the interaction could be detected from ACT. Whichever digital format ACTs are registered (such as XML), a simple process could be executed in order to detect automatically the interactions.
4.2. Risk Assessment and Recommendation of Resolutions
After the interaction is detected it is possible to asses its risk and reason about the resolution method required. If the business rules are not mutually excluding, the critical point is posed on the information used by each business rules. The information required by business rules is in the core modules, then connections transfer the information from core to business rules. The aspect mechanism which enables this operation is known as “Exposing Context”. For example, in AspectJ-like languages it is possible to pass the intercepted object and/or method arguments (by means of this, target and args primitives). Another point to consider is how event context is used by business rules whose connections are superimposed. The information can be used in three ways: to read, to write or to read/write.
The risk of interaction could be categorized in four levels: null, low, medium and high.
1) Null Risk: this level of risk indicates the interaction is not dangerous and then is not necessary an explicit resolution. This level of risk occurs when the information used by two connections is not the same.
2) Low Risk: this level of risk denotes that although aspects execution requires a sequence, this sequence is not mandatory, then the order in execution is not crucial. This level of risk occurs when the connection uses the same information only for reading.
3) Medium Risk: this level of risk denotes that aspects execution requires a sequence, this sequence is mandatory, then an explicit resolution is required. This level of risk occurs when both connections uses the same information, one of them writes it, and the another reads it.
4) High Risk: this level of risk denotes that interaction must be managed by developer because of both connections update the same information.
A simple example (Figure 2) is used to show how an interaction can be analyzed. Suppose a store where an invoice (Invoice) is issued when a customer (Customer) buys any product (Item). An Invoice consists of some fields such as number of invoice, date of invoice, Customer name, an array of items, subtotal, discount and total. By default, discount field is initialized with cero and the name of Customer is initialized when invoice is instanttiated. Customers have a rewards card in order to add up points. Each time they make a purchase a business rule (BR#1) calculates the points to credit to the card.
Table 1. Points of potential interaction.
BR#1: After the system calculates the total of the invoice, every $10 a point must be credited to the rewards card. BR#1 should be implemented by CreditRewardsCard class and RCConnection is the aspectual connection (Figure 3).
RCConnection is “query” connection, because of information required by business rule, RewardsCard is not available in the main event. RewardsCard object should be retrieved previously, when the name of customer is initialized.
BR#2: The anniversary of the store is next month, so a special raffle would be organized. The customers participate with their purchases. After the system computes the total of the invoice, every $15, 2 raffle tickets are given. BR#2 is implemented by PrintRaffleTicket class and PRTConnection is the aspectual connection (Figure 4). PRTConnection is a “basic” connection.
Figure 5 shows how analysis can be performed. The aspectual connections that are interacting are identified, as well as the business rules that these connections trigger. The shared event and the moment when the interacttion occurs are specified. Afterwards the event context used by each business rule is analyzed. In this case, both business rules read the same information (Invoice.total field), but they write different information (RewardsCard and Ticket objects). Then according to the indicated risk proposed, the level of risk of this interaction is low.