FORMAL DEFINITION OF BUSINESS RULES USING REA BUSINESS MODELING LANGUAGE Frederik Gailly1 and Guido Geerts2 1 Faculty of Economics and Business Administration, Ghent University [email protected] 2 University of Delaware [email protected] Abstract: In this short paper the REA Business modeling language is extended with an REA Business Rule modeling language. Developing a graphical rule modeling language must make it easier for business people to specify rules without ignoring the actual application of the rules in practice. This application is supported by adding a set of transformation rules to the REA metamodel and REA Business Rule metamodel which support the transformation of the REA model and accompanying rules into a UML class diagram with accompanying OCL constraints. 1 Introduction A business rule is defined by Von Halle [1] as a statement that aims to influence or guide behavior and information in an organization. Business rules have mostly been determined ad hoc during the software modeling process and they have been hardwired into code without proper documentation at the conceptual level [2]. Recently the explicit specification of Business Rules has gained more attention. For instance the Object Management Group (OMG) has adopted the SBVR specification which defines a language that can be used for creating business vocabularies and rules of all kinds of business activities of all kind of businesses [3]. In this paper a domain-specific modeling language instead of a general-purpose language like SBVR is used for specifying business models and business rules. The last 10 years different business modeling languages have been proposed which define enterprise domain specific constructs that can be used to develop business models and possibly also business rules. A well-known business modeling languages which indirectly support business rules specification is the Resource Event Agent (REA) business modeling language [4]. Although the REA language could be defined independently, it is most used as an extension of general purpose modeling language like UML Class diagrams or Entity Relationship (ER) modeling. Consequently the REA modeling language inherits the features of these general-purpose languages, of which some can be used to specify business rules. For instance if REA is defined as an extension of the ER metamodel, adfa, p. 1, 2011. © Springer-Verlag Berlin Heidelberg 2011 the multiplicities of ER modeling can be used to specify business rules or if REA is defined as an extension of UML class diagram, the Object Constraint Language (OCL) can be used to incorporate more complex business rules. The problem with this approach is that successful integration of business rules into the REA-model requires knowledge about these general purpose modeling languages. Knowledge that is in most cases not present. In this paper we take a different approach and define the REA modeling language independently. This language can be used to create business models but does not support the creation of business rules. Instead the specification of the business rules is supported by another related modeling language, the REA Business Rules Language (REA-BR). We believe that making a clear distinction between the business modeling language and the business rule modeling language with both their own syntax, will make it easier for business experts to create both type of models. However this improved ease of use may not effect the actual implementation of the rules. In the context of model-driven engineering this means that it must be possible to transform the business models and business rules (i.e. Computation Independent Models) into software design models (i.e. platform independent models) and later into actual code (i.e. platform-specific models). In the next section the meta-models of the REA and REA-BR language are represented and explained using an example. In section three Model-to-text and Model-toModel approaches are used to demonstrate how the business model and accompanying rules are transformed into a class diagram with OCL constraints. Section 5 concludes this research. 2 REA Business Modeling Language and REA Business Rule Modeling Language The meta-model that defines the REA Business Modeling language is represented in figure 1. This meta-model specifies the REA Business Modeling language like it was originally introduced by McCarthy [4] and extended by Geerts and McCarthy [5] in 2006. This recent extension introduced the grouping and typification abstraction mechanism in REA which allows to add a policy layer to the REA operational level which is absolutely necessary in order add different type of business rules to the REA models. The grouping and typification abstraction mechanism are not specific for REA but are abstraction mechanisms that have been described by other authors. Typification present archetypal essence and are timeliness in nature. They are used for capturing concept descriptions that apply to a set of objects (e.g Plane is a kind of PlaneType). Grouping is a considered as a special kind of aggregation and it groups objects into collections based on one or more characteristics (e.g. Plane is member of Fleet). In our metamodel the introduction of these policy relations results in the addition of REAPolicyRelationship Element which connects a REAOperationalEntity to a RE- APolicyEntity. The distinction between grouping and typification is made by adding a the policyRelationshiptype attribute to the REAPolicyRelationship. Figure 2 demonstrates the instantiation of this metamodel and represents an REA business model for a consulting firm. The firm promises to deliver Consulting Services that are grouped in a Consulting Service Task that needs to be executed by a specific set of employees that have some expertise. The actual execution of the service is also included by means of the Deliver Consulting Services Economic Event which specifies by which employee the Consulting Service is delivered. Figure 1: REA metamodel Figure 2: REA Business Model Consulting Firm The metamodel in figure 3 represents our main contributions and allows a business user to graphically represent Business Rules. The figure also shows that the REA Business Rule metamodel incorporates some of the concepts defined in the REA Business metamodel. Following the paper of Geerts and McCarthy 2 different kind of Business Rules are identified: Participation Policies, and Attribute Validation Policies. This set will be extended in future versions of the paper. ─ Participation Policy are used to put a constraint on the number of operational entities that can be member of (grouping) or can be a-kind-of (typification) a Policy Entity. For instance the Participation Policy can be used to specify the following BR: “The number of consulting services delivered by a ConsultingFirm is larger or equal than the minimal number of consulting services required for that task.” Table 1 shows how this BR can be specified by instantiating the REA BR metamodel. In the future we plan to extend the metamodel with a graphical notation which is more intuitive to use. ─ The AttributeValidationPolicy validates an attribute value of a REA Operational Entity against a value of attribute of a PolicyEntity. For instance the AttributeValidationPolicy can be use to specify that: “the salary of an employee must be equal or greater than the minimum salary of the department she works for” Figure 3: REA Business Rule metamodel Table 1: Participation Policy for Min Number Of Consulting Services Required Name Operator policyEntity policyAttribute policyRelationship minNumberOfConsultingServicesRequired greaterOrEqualsThan Consulting Service Task Min#OfConsultingServices ConsultingServices_ConsultingServicesTask Table 2: Attribute Validation Policy for Minimum Salary Name operator policyEntity policyAttribute operationalAttribute policyRelationship minimumSalary lessOrEqualsThan EmployeeType minSalary minSalary Employee_EmployeeType 3 Transformation REA models into UML class diagram For the transformation of the business model and accompanying rules we use ATL and MTL. Both ATL and MTL are supported by Eclipse plug-ins that use the Eclipse EMF framework. The two projects that contain our mapping rules and also apply these rules on the REA Consulting Firm business model and rules can be downloaded from http://code.google.com/p/reamodeller/. The output of both the ATL and MTL transformations is represented in figure 4. ATL is a model-to-model transformation language that is used to create a UML class diagram from the REA business model. This transformation is in most cases straightforward: 1) REA Entities and their attributes are transformed in UML classes with accompanying attributes, 2) REA relationships with no attributes are transformed in bidirectional associations and 3) REA relationships with attributes are transformed into association classes with accompanying attributes. Less straightforward is the inclusion of the multiplicities. Generally the ATL transformation rule for relations adds a participation of zero and a cardinality of many to the roles of every association. However in some cases theses multiplicities are more specific based on the definition of the REA concepts, relations and axioms. For instance following one of the REA axioms “every Economic Event must have at least one participating Economic Agent and at least one Economic Resource” which can be transformed into an ATL rule. The policies that are represented using the REA BR metamodel are transformed into OCL using MTL. MTL is a model-to-text transformation language and allows to specify a template for every type of REA policy. These templates transform the policy in a corresponding OCL constraint. The result of the transformation of the examples in table 1 and table 2 are represented in the comments in figure 4. Figure 4: UML class diagram Consulting Firm 4 Conclusion The main contribution of this paper is the development of a REA business modeling language that is extended with an REA Business Rule meta-model which allows a business expert to specify business rules. The paper also demonstrates how the developed REA Business Model and accompanying rules can be transformed into a UML class diagram with OCL constraints. Currently the set of business rules that is supported by the REA Business Rule meta-model is limited and in future research we plan to further extend this. Additionally we also need to provide an easy to use graphical notation for the business rules meta-model. References 1. Von Halle, B.: Business rules applied : business better systems using the business rules approach. Wiley Computer Publishing, New York (2002) 2. Steinke, G., Nickolette, C.: Business rules as the basis of an organization's information systems. Industrial Management & Data Systems 103, (2003) 3. OMG: Semantics of Business Vocabulary and Business Rules (SBVR), v1.0. (2008) 4. McCarthy, W.E.: The REA Accounting Model: A Generalized Framework for Accounting Systems in A Shared Data Environment. The Accounting Review 57, 554-578 (1982) 5. Geerts, G., McCarthy, W.E.: Policy-Level Specification in REA Enterprise Information Systems. Journal of Information Systems 20, 37-63 (2006)
© Copyright 2024 Paperzz