Transformation Rules for Translating Business

Transformation Rules for Translating Business Rules to OCL Constraints Imran S. Bajwa and Mark G. Lee School of Computer Science, University of Birmingham, B15 2T, Birmingham, UK {i.s.bajwa,m.g.lee}@cs.bham.ac.uk

Abstract. In design of component based applications, the designers have to produce visual such as Unified Modeling Language (UML) models, and describe the software component interfaces. Business rules and constraints are the key components in the skeletons of software components. Semantic of Business Vocabulary and Rules (SBVR) language is typically used to express constraints in natural language and then a software engineer manually maps SBVR business rules to other formal languages such as UML, Object Constraint Language (OCL) expressions. However, OCL is the only medium used to write constraints for UML models but manual translation of SBVR rules to OCL constraints is difficult, complex and time consuming. Moreover, the lack of tool support for automated creation of OCL constraints from SBVR makes this scenario more complex. As, both SBVR and OCL are based on First-Order Logic (FOL), model transformation technology can be used to automate the transformation of SBVR to OCL. In this research paper, we present a transformation rules based approach to automate the process of SBVR to OCL transformation. The presented approach implemented in SBVR2OCL prototype tool as a proof of concept. The presented method softens the process of creating OCL constraints and also assists the designers by simplifying software designing process. Keywords: Model Transformation, Transformation Rules, OCL constraints, SBVR business rules, SBVR business design.

1 Introduction Software modeling is a major phase of software development and the growing complexity of large software systems can be handled using the modeling approach. Unified Modeling Language (UML) is an essential tool for developing high-quality, possibly error-free, and highly accurate models of complex and mammoth-sized software systems. However, a UML model remains semantically incomplete without constraints. Constraints further restrict the behavior of objects in a UML model. Object Constraint Language (OCL) is a formal specification language [1] used to define constraints for a UML model. But adaptability of OCL has been a major issue since it has emerged into an Object Management Group (OMG) standard [2]. Less adaptability of OCL is due to unfamiliar syntax of OCL [11] and lack of built-in support in OCL specification for standardized semantic verification [3]. Existing OCL tools just perform type checking and parsing of OCL expressions [12], [13]. R.B. France et al. (Eds.): ECMFA 2011, LNCS 6698, pp. 132–143, 2011. © Springer-Verlag Berlin Heidelberg 2011

Transformation Rules for Translating Business Rules to OCL Constraints

133

Currently, there is no tool that facilitates easy creation of OCL constraints from business rules. SBVR (Semantic of Business Vocabulary in Rules) [7] is an OMG specification used for expressing business/software requirements for business/software models in the form of business rules. A Business rule is key element of SBVR based business/software models. SBVR has replaced the natural languages to capture business/software requirements due to inherent support of formal semantics in SBVR. The business/software constraints can also be represented using SBVR (rules) as SBVR promises semantically consistent representation to the software/business constraint specifications. In SBVR, semantic consistency is achieved due to SBVR’s inherent support of formal approaches: typed predicate logic; arithmetic; set and bag comprehension, and with some additional basic results from modal logic [7]. As the logic is essentially classical logic, so mapping to other logic-based specifications such as OCL should be simple as OCL is also based on typed logic, First-Order-Logic (FOL) [3]. This work is extension of the automated generation of natural language specification to OCL constraint via SBVR [19], [22]. The automated transformation of SBVR rules to OCL constraints simplifies the process of manually generating OCL constraints from SBVR representation as manual generation is not only difficult and complex but also causes erroneous OCL expressions [3], [11]. The proposed methodology for the transformation of SBVR rules to OCL constraints is based on set of transformation rules. Transformation rules based SBVR to OCL mapping is shown in Figure 1. OCL Model

SBVR Model

Transformation Rules

Fig. 1. Transformation rules to map source model (SBVR) to target model (OCL)

Following section gives the brief description of SBVR and OCL elements. 1.1 SBVR Constraints SBVR [7] is typically used by business people to capture business requirements specifications and constraints. In business models, constraints are represented using business rules. The business rules in SBVR are assembled on facts, and facts build on concepts as expressed by terms. Terms express business concepts; facts make assertions about these concepts; rules constrain and support these facts. For example in a business rule “customer uses a credit card”, used concepts are ‘customer’ and ‘credit card’ and this rule is based on a fact-type ‘customer uses card’ while ‘uses’ is a verb concept. In this example, given concepts are noun concepts. Concepts can also be individual concept e.g. ‘VISA card’. In SBVR, a business rule can be of two types: structural rule and behavioral rule [7]. A structural rule is used to express state or structure of a noun concept for

134

I.S. Bajwa and M.G. Lee

example a structural rule “customer has a bank account” expresses the state of a noun concept ‘customer’ who has a ‘bank account’. A behavioral rule principally describes the operations or actions performed by a noun concept. For example in a behavioral rule “customer deposits money” it is given that a noun concept ‘customer’ performs an action of depositing ‘money’. Two notations are proposed for SBVR rules in SBVR 1.0 [7]: Structured English and RuleSpeak. In this paper, we have used Structured English as a formal notation for SBVR rules [10]. The SBVR structured English notation proposes to underline the noun concepts, italicize the verb concepts, double underline the individual concepts, and bold the SBVR keywords. The above SBVR rules with logical formulations are written using defined notation of Structured English. 1.2 OCL Constraints The Object Constraint Language (OCL) is another important standard from OMG used to annotate UML models with logical constraints to avoid semantic ambiguities. OCL is a declarative language that is mainly used to define constraints on a UML class models, and define queries for it. OCL Syntax: To define the basic structure of n OCL expression, OCL syntax is defined in OCL 2.0 [3]. The syntax of a typical OCL expression is mainly composed of the following three components. Context: A context [3] in an OCL expression specifies the scope of the expression. The OCL context limits a world of an expression in which it is valid using a keyword ‘context’. A keyword ‘self’ is used to refer a particular class or operation of a class specified in a context. Property: An OCL property [3] represents an attributes or operation of a class. ‘.’ operator is used to specify these properties e.g. customer.account or customer.deposit()

Keyword: The OCL keywords [3] e.g. if, then, else, and, or, not, implies are typically used to specify the conditional expressions. OCL Constraints: An OCL constraint defines a Boolean expression that can result in True or False. If a constraint is always true, the system remains in a valid state. An OCL constraint can have following 3 types: Invariants: The invariants [3] are conditions those need to be True always. Keyword ‘inv’ is used in invariants. context customer inv: self.age >= 18

Precondition: A precondition [3] is a constraint that should be True before the execution of a method starts. Keyword ‘pre’ is used in preconditions. context customer :: isAdult(dDOB: Integer): Boolean pre: dDOB >= 1990


135

Postcondition: A postcondition [3] is a constraint that should be True after the execution of a method has finished. Keyword ‘post’ is used in postconditions. context customer :: isAdult(dDOB: Integer): Boolean post: result >= 18

The rest of the paper is structured as follows. Section 2 describes the methodology for the translation of UML class diagrams into SBVR rules and transformation rules used to translate the SBVR abstract syntax into the OCL abstract syntax. All the transformation rules are illustrated by examples. Section 3 describes a prototype translation tool OCL-Builder, whereas section 4 describes experiments, results and analysis. Section 5 presents the related work to our research and the paper is closed with the conclusion section.

2 SBVR to OCL Transformation SBVR to OCL transformation is performed in two phases. In first phase, the SBVR constraints specification is mapped to the target UML model and in second phase the SBVR information is mapped to OCL constraints using a set of transformation rules. Detailed description of both phases is given here: 2.1 Mapping SBVR Rules to UML Model In this phase, the SBVR rules are mapped to UML models for semantic verification before the SBVR rules are mapped to OCL constraints. Semantic verification is essential to validate that the target OCL constraints will be semantically verified with the target UML model. To illustrate the process of mapping SBVR rules to the UML model we have taken an example shown in Figure 2. Customer - name: String - birthDate: Date - age: String - isAdult(): Boolean

has

BankAccount

1 .. *

- owner: String - balance: GBP=0 -deposit(amount:GBP) -withdraw(amount:GBP)

SavingAccount - insertRate: Double

Fig. 2. A UML class model

The mapping process starts with the syntax analysis of SBVR rules to extract various elements of the SBVR rule i.e. noun concepts, verb concepts, fact types, etc.

136


Following section describes the process of mapping classes and their respective associations with a common SBVR rule. Mapping Classes: The general noun concepts in SBVR rules represent the UML classes. Verb concepts specify methods of a class. Adjectives are tagged as attributes. An example of a SBVR rule is given below: It is obligatory that each customer can have at least one bank account only if customer is 18 years old. In the above shown SBVR rule, both noun concepts ‘customer’ and ‘bank account’ are matched to all classes in the UML class model shown in the figure 2 and the noun concepts are replaced with the names of the classes, if matched. Mapping Class Associations: Associations in a UML class model express relationship of two entities in a particular scenario. A UML class model may consists of different types of associations e.g. packages, associations, generalizations, and instances. Typically, these associations are involved in defining the context of an OCL constraint, so it is pertinent to map these associations in the target SBVR specification of business rules. Mapping Packages: A package in a UML class model organizes the model's classifiers into namespaces [20]. In SBVR, there is no specific representation of a package. Hence user has to manually specify the package name for a set of classes. The package names are also defined in the OCL constraints, so the package information is also mapped to the SBVR rules. Mapping Associations: Associations in a UML model specify relationships between two classes [20]. Simple associations can be unidirectional, bidirectional, and reflexive [18]. Unidirectional associations in UML are mapped with unary (based on one noun concept) fact types in SBVR and the bidirectional associations in UML are mapped with binary (based on two noun concepts) fact types in SBVR. Direction of the association is determined by the position (subject or object) of the noun concepts and object types in SBVR. Mapping Generalizations: Generalization or inheritance is an association between two classes that defines the property of one class inheriting the functionalities of the other [20]. In SBVR the relationship of general noun concept (super class in UML) and individual noun concept (sub class in UML) is used to identify the inheritance feature. If a class A inherits the class B then the class B will also be the part of OCL context of class A. Mapping Instances: The instances of the classes can also appear in a UML class model. The individual concepts in SBVR are mapped to the instances (objects). The defined instances also become part of the OCL contexts and OCL constraints. So, the instances are also mapped in SBVR rules. In SBVR to UML mapping, the classes that do not map to the given UML class model are ignored.


137

2.2 Mapping SBVR Rules into OCL Constraints We present an automated approach for the translation of the SBVR specification into the OCL constraints. Our approach not only softens the process of creating the OCL syntax but also verifies the formal semantics of the OCL expressions with respect to the target UML class model. As OCL is a side-effect free language, hence it is important that each OCL expression should be semantically verified to the target UML model. A prototype tool “SBVR2OCL” is also presented that performs the target transformation. Figure 3 shows a SiTra library [21] based Model Transformation Framework for SBVR to OCL Transformation using (SBVR to OCL) mapping rules.

SBVR Metamodel

Mapping

OCL Metamodel

Rules

SiTra – A MT Framework

SBVR Modal

OCL Modal

(Source Model)

(Target Model)

Fig. 3. A SiTra based Model Transformation Framework for SBVR to OCL Transformation

Mapping of SBVR rules to OCL code is carried out by creating different fragments of OCL expression and then concatenating these fragments to compile a complete OCL expression. Typically, OCL expression can be of two types: OCL invariant and OCL query operation. In this paper, we will present only the creation of OCL invariants and the creation of OCL query operation is part of the future work. The SBVR rules’ specification created in section 2 is further analyzed to extract the business information as follows: It is obligatory that each at least one only if The analyzed SBVR rule is further transformed to the logical representation after omitting the SBVR keywords as following p ⇒ q if p → function1() AND q → q.function2() This logical representation can be further generalized as follows: p ⇒ q if condition1 = TRUE AND condition2=TRUE This generalized representation is finally transformed to the OCL constraint by using the defined transformation rules. A typical transformation rule comprises of the variables, predicates, queries, etc [9]. A typical transformation rule consists of two parts: a left-hand side (LHS) and a right-hand side (RHS). The LHS is used to access

138


the source model element, whereas the RHS expands it to an element in the target model. The transformation rules for each part of the OCL constraints are based on the abstract syntax of SBVR and OCL that are given in the following section. Generating OCL Context: The context of an OCL expression defines the scope of the given invariant or pre/post condition. To specify the context of an OCL invariant, the major actor in the SBVR rule is extracted to specify the context. To specify the context of an OCL pre/post condition, the action performed by the actor in a SBVR rule is considered as the context. Rule 1.1 shows the OCL context for invariant expressions and Rule 1.2 shows the context of for the pre/post condition of an operation: Rule 1.1 T[context-inv(object type)] = context-name

Rule 1.2 T[context-cond(object type, verb concept)] = context-name :: operation-name

Precondition and postcondition can co-exist in a single an OCL expression than the both precondition and postcondition share the same context. Generating OCL Constraints: Transformation rules for mapping of the SBVR specification to OCL constraints are defined in this section. There are two basic types of an OCL constraints; invariant of a class, and pre/post condition of an operation. Constraint on a class is a restriction or limitation on a particular attribute, operation or association of that class with any other class in a model. An expression for these constraints consists of two elements: context of the constraint and body of the constraint. R0u le 2.1 T[invariant( context-inv, inv-body )] =

context context-inv inv: inv-body

Rule 2.2 T[pre-cond ( context-cond, pre-cond-body )] = context context-cond pre: pre-cond-body

Rule 2.3 T[post-cond ( context-cond, post-cond-body )] =

context context-cond post: post-cond-body

Generating OCL Invariants: The OCL invariant specifies a condition on a class’s attribute or association. Typically, an invariant is a predicate that should be TRUE in all possible worlds in UML class model’s domain. The OCL context is specified in the invariants by using self keyword in place of the local variables. Rule 3.1 T[inv-body ( ocl-exp )] = inv: ocl-exp

An invariant can be expressed in a single attribute or set of attributes from a class. In OCL, collection operations are used to perform basic operations on the set of attributes.


139

Rule 3.2 T[ ocl-exp()] = self . ( Expression | collection-exp | if-exp )

Rule 3.3 T[collection-exp(Expression)] = Expression → collection-op | Expression → collection-op → collection-exp | “”

Rule 3.4 T[if-exp( Condition, Expression )] = If Condition then Expression-1 else Expression-2 endif

Generating OCL Pre/Post Conditions: Similar to the OCL invariant, the OCL preconditions and the OCL postcondition are used specify conditions on operations of a class. Typically, a precondition is a predicate that should be TRUE before an operation starts its execution, while a postcondition is a predicate that should be TRUE after an operation completes its execution. Rule 4.1 T[pre-cond-body( ocl-exp )] = pre: ocl-exp

Rule 4.2 T[post-cond-body( ocl-exp, value )] = post: ocl-exp | post: result = value

Rule 4.3 T[value( thematic-object )] = Integer-value | Double-value | String-value | Boolean-value

A pre/post condition can be expressed in a single attribute or set of attributes from a class. Rule 3.2 and 3.3 are reused here to accompany Rule 4.1 and 4.2. In rule 4.3 the attribute value is verified that the provided value is of accurate type e.g. integer, double, or String, etc. Generating OCL Expressions: The OCL expressions express basic operations that can be performed on available attributes of a class. An OCL expression in the OCL invariant can be used to represent arithmetic, and logical operations. OCL arithmetic expressions are based on arithmetic operators e.g. ‘+’, ‘–’, ‘/’, etc, while, logical expressions use relational operators e.g. ‘’, ‘=’, ‘’, etc and logical operators e.g. ‘AND’, ‘implies’, etc. Rule 5.1 T[Expression( Expression )] = Expression infix-oper Expression | prefix-oper Expression

Rule 5.2 T[infix-oper(Quantification )] = +|-|*|/|=|>|=|