Semantics in Model-Driven Business Design

This position paper describes ongoing work in applying the new OMG standard called Semantics in Business Vocabulary and Rules (SBVR) to a model-based approach to business design and implementation. The work explores methods of specifying semantics and rules in SBVR’s “Structured English” as extensions of business models that are automatically translated to executable solutions. Introduction The Object Modeling Group’s (OMG’s) Model-Driven Architecture [13] concept defines a multi-layered approach to defining business solutions, as shown in figure 1. Platform Independent Model (PIM) Platform Specific Model (PSM) Business model Technology independent model Technology specific model M aping M aping Business Model (CIM or Computation Independent Model) e.g. business processes, organization structure, business metrics – expressed without implementation details e.g. BPDM (Business Process Definition Metamodel from OMG) e.g. BPEL (Business Process Execution Language) flows e.g. models tied to J2EE, . Net Fig. 1. OMG Modeling Layers Figure 2 summarizes OMG efforts to define standards for rules at the top two layers. The Semantics of Business Vocabulary and Rules [15] activity is defining a “Structured English” approach to vocabulary and rules at the Business Model or Computation Independent Model layer. The Production Rules Representation [14] aims to specify a standard Unified Modeling Language (UML) model for rule structures. Platform Independent Model (PIM) Platform Specific Model (PSM) M aping M aping Semantics of Business Vocabulary & Rules (SBVR) Business Vocabulary Business Rules Production Rules Representation (PRR) • Forward chaining • Sequential Rules Vendor-Specific Rule or Other Language Business Model business guidelines e.g. “the duration of each rental must be at most 90 days” rules located within a solution e.g. “in the rental pickup flow, if the rental duration is greater than 90 days then . ” e.g. “in the rental reservation UI, if the rental duration is greater than 90 days then . ” ? rule language or hard code e.g. “if rental.duration > 90 then . ” Fig. 2. Rules in the MDA Layers This paper summarizes an ongoing effort to implement a subset of SBVR in the context of an existing Model Driven Business Transformation project [10] at IBM Research. MDBT – Model-Driven Business Transformation MDBT is a methodology and matching toolkit for defining a business solution at the business modeling layer, and then semi-automatically transforming the solution into a PIM-layer and then a PSM-layer implementation. A business analyst applies the methodology by defining a business model using the IBM WebSphere Business Modeler [7] tool and the MDBT semantics. The analyst then converts the business model to a PIM-layer model using the IBM Rational Software Architect [6] product, and further transforms the PIM-layer model to an executable implementation using the IBM WebSphere Integration Developer [8] tool and IBM WebSphere Process Server [9] runtime. The generated implementation includes Data Definition Language (DDL) statements to generate relational database tables, state machine definitions for executing the solution, skeleton user interface Java Server Pages (JSPs), and service definitions in the form of Web Services Definition Language (WSDL) files. The implementation incorporates business performance monitoring functions and dashboards, as described in [2]. The transformation process from business layer to implementation can be fully automated in a “rapid prototyping” mode. Manual intervention at the PIM and PSM layers are needed to produce production-quality user interfaces and adapters for invoking legacy systems as services. user role business artifact verbs: reject, validate Fig. 3. Business-Layer Model of a Driver’s License Bureau Figure 3 shows a simple solution example at the business layer. This shows the processing flow of a Driver’s License Bureau which handles License Applications. The flow starts at the dot on the left, and proceeds through the illustrated stages. The rounded squares show processing tasks, while the database icons show repositories for holding in-process work. The rectangular callouts indicate the three primary concepts captured in this model: user roles, verbs associated with the output sides of tasks, and the business artifacts processed by the solution. Fig. 4. Business Artifact At the business layer, artifacts are detailed in terms of their attributes. Figure 4 shows that a License Application contains various fields, similar to properties in UML classes. What’s missing from the business-layer model is any concept of business rules. For example, perhaps the applicant must be at least 18 years old to get a driver’s license. In the current MDBT approach, such rules must be implemented manually at the PSM layer. A method of specifying such rules at the business layer and then transforming them to the implementation would improve the MDBT methodology. The objective of this project is to examine the suitability of SBVR for this purpose. SBVR SBVR provides a framework for defining business vocabulary and rules at the business modeling layer using “Structured English” and applying stylized text to four key concepts: − The ‘term’ style applies to noun concepts, such as ‘License Application’. − The ‘Name’ style designates individual concepts, such as a clerk named ‘Bill’. − The ‘verb’ style identifies fact types, which define relationships between concepts. For example, ‘clerk validates application’. − The ‘keyword’ style distinguishes various words used to construct vocabulary definitions and rule statements. The keywords designate built-in SBVR concepts such as ‘it is permitted that’ and ‘exactly one’. SBVR supports standard logical operations (‘and’, ‘or’, and so forth) and first order predicate logic (e.g. ‘each’, ‘some’). SBVR also supports certain modal logic concepts such as necessity, possibility, obligation, and permission. Some example rules given in “Structured English” are: It is permitted that each clerk validates each license application only if the current age of the license application is greater than 18. It is obligatory that each applicant pass the written test. Note the influence of the vocabulary design on the expression of the rules. The first example references the “the current age of the license application,” rather than “. of the applicant,” because “current age” is a field of the “license application” artifact. The vocabulary – and perhaps the underlying application – would have to be restructured to enable a more natural rule statement. The project described here is creating a prototype tool to evaluate the technical issues involved in writing SBVR rules, and then transforming them to executable implementations.