  
|
|
Autores: M.Sc. Martha Beatriz Boggiano Castillo, mbeatriz@uclv.edu.cu; Lic. Alaín Pérez Alonso, apa@uclv.edu.cu; M.Sc. María Elena Martínez del Busto, mmbusto@uclv.edu.cu; Dr. Ramiro Pérez Vázquez, rperez@uclv.edu.cu; Dra. Luisa González González.
Key words: Business rules, automatic code generation, restriction rules.
Los problemas en la concepción de Sistemas de Información, debido al tratamiento informal de los requerimientos, han permitido considerar como factor de esencial importancia la forma en que se manejan los requisitos, enfocados actualmente como reglas de negocio. El propósito de este trabajo es generar automáticamente las reglas de restricción en un sistema de información, específicamente aquellas que puedan residir en la base de datosganando con esto agilidad, transparencia y reducción del costo en un negocio. Se describen algunos beneficios de usar reglas de negocio. Se usa un patrón para estas reglas, analizando los recursos que posibiliten su implementación en una base de datos y determinar su forma de almacenamiento. Se modifica un patrón de reglas adaptándolo a las nuevas exigencias de las reglas, seeligen los recursos de bases de datos para implementarlas, y se construye un compilador que genere este código. Palabras clave: Reglas de Negocio,generar código automáticamente, reglas de negocio de restricción.
Introduction By automating this process, failures are avoided and in this way time and cost are significantly reduced. In order to automate these "requirements" a system is needed to give them functionality so that they are implemented in a given language and stored for safe handling. Current studies tend to store the rules in a repository where they are handled by an independent engine rule. Therefore, restrictions are not codified in the system and this can only make necessary accesses to the repository. The idea of business rules, as a definition of the desired policy, would provide a solution for its possible treatment in databases and the benefits it provides. There are several potential advantages of using Business Rules. Of all, according to Lowenthal (Lowenthal, 2005), the three most important are:
Implementation of Business rules There are many types of business rules. Due to their complexity and diversity, authors tend to group classify them according to different points of view. One of these classifications is was given by Solivares, Lowenthal, Morgan (Perez, Boggiano 2007). These classifications were analyzed and Morgan’s classification was finally adopted in this paper since it takes into account a more elaborate classification of rule patterns, and therefore it was considered the most suitable of all. The restriction rules are those restricting the data in the system and they may overlap with the rules of the data model, since those also prevent the introduction of erroneous data. The difference lies on the fact that the restriction rules determine the value attributes or properties of an entity beyond the basic restrictions. The rules can be implemented in different ways and even there could be different techniques for the same rule. Morgan (Morgan, 2002) shows some of them: Programming Languages, Scripts, Database. In the case of SQL Server, programming can be made in a dialect called Transact-SQL. The most usual procedure is to use business rules in respect to functional words around the basics (CREATE, READ, UPDATE and DELETE). These mechanisms are common to all data services: restrictions (Constraints) CHECK, trigger, views, user-defined functions and assertions. Here we are working with triggers and functions in order to implement the restrictions rules on the business database. The pattern suggested by Morgan for the basic restricting rule is the following: <determinant> <subject> [no] (must | have) <characteristics> [(If | unless) <fact>].
Table.1 Elements of Pattern.
The conventions used for the patterns in this work are as follows:
A case of basic restriction and list of restrictions. We present a rule of business for a kidney transplant. Natural Language: A patient can not take potential donors with more than 4 physical exams or have in his evolution a higher maximum temperature of 42 degrees. This way of expressing this rule very close to the customer is called natural language, taking into account the pattern adopted. In order to achieve an SQL implementation, an intermediate representation is considered (called the technical language); to represent the rule in technical language, the representation of the rule is used, where the navigational point is used (Morgan, 2002). This style is used in the technical language to access the attributes of the entities and browse the relationships between them. Simple access to an attribute: Browse between entities relationships: For example, if one needs to access the patient's name, it can be reached by writing Patient.Name. However, it is also possible to browse it in the relationships of the following schedule:
When using the notation point navigation to establish the relationships between entities and accessing their attributes, two main types of results could be obtained, due to the cardinality between the business objects. This is because it can be specified either as a single member of the business or referred to a set of them and therefore it is necessary to discern between both cases. Multiple elements: By stating "The Patient's evolutions ..." (Patient.Evolution) several evolutions related to a unique patient are designed as shown in the cardinality of the diagram. Note again that the order of the notation is very important. An expression of a rule in technical language would be: In natural language the corresponding expression to this rule would be: The Triggers and functions in implementing the rule. It is significant to reach a consensus on when you should use the various resources of SQL99, according to the peculiarities of the rule and how such restrictions of the business will be implemented. This will provide a tool to select the form of generating the rule. Applying rules of restriction patterns in a database for kidney transplant. The code generator will produce in the SQL Server database of the business of kidney transplant the following function and trigger: The function: The trigger: These triggers, as can be noted, state a @subject that is the conditioned <subject> to the rule, which is extracted through a query defined by the point notation. Afterwards, in a conditional sentence it is questioned whether the rule is shattered or not to the specified subject on whom a relational modification was done; if so, then suitable measures are adopted. The function is the body of the rule. Triggers will refer to a function. This is the one responsible to perform the body of the rule where it is verified if the subject breaks the conditions imposed by the restriction. Its objective is to reply if any of the prohibitions is infringed by using a Boolean value. The function FRN#0 is called from the trigger. Implementation, operators and functions. The process of compiling business rules, restriction type, used in the current version of an editor of rules in technical language is performed since the first moment you execute. During this process part of the resulting code is being directly generated and the rest is formalized in the corresponding application. This compiler is composed of two other compilers, one of these is engaged in compiling the <characteristics>, and the other is engaged in the <facts>.The compilation process is shown in this activity diagram:
llustration 2. Diagram in the Collection Activity or translation.
With Yacc, given the BNF (Backus Normal Form) of grammar specification, the corresponding parser can be generated. Yacc does not accept every grammar presented; however, the kind of grammar that it accepts is generally powerful and enough for the needs of programming (Bumble-Bee, 2000). In Lex it is mainly defined the data types, the operators and the functions that are accepted in the technical language; they are useful for shaping the grammar of the rule, restriction type. Only triggers and functions are generated. Efforts are being made to improve this compiler, to represent CHECK restrictions, to do a rigorous check type and to evaluate the repercussion of the business rule transformation in the business database. Currently, the software is being validated to implement a set of business rules to the problem of kidney transplant in an SQL Server database and work is being done on a version of the MySQL 5.x software database.
This article has addressed the need to deal with the requirements of the system using the approach of business rules, showing their dominance in the process of managing the organization in order to have a potential for a drastic reduction in the number of errors.Business rules, classified as restriction types, are formalized in a pattern of rules of business, based on the pattern proposed by Morgan. A program that compiles these rules was built and used starting from entries of the rules in technical language. Using the navigation point in which the rule entries in the pattern were made considerations were adopted for each part of this pattern and a trigger was automatically created for insertion and update which implements a restriction rule to a information system SQL Server 2000 database. Also examples are presented for a database of kidney transplants. This compiler will be valid for any business using a business database in SQL Server 2000. Automation to generate business rules helps to avoid failures, achieving significant reductions of time and cost.
 Book
Journal
|
