Extensión del BPMNO para el enfoque de reglas de negocio en el desarrollo de sistemas

Gomes Figueiredo, José; Pereira Marín, Carlos Alberto

Research article

Extensión del BPMNO para el enfoque de reglas de negocio en el desarrollo de sistemas

Extension of BPMNO for the business rules approach on software development

Gomes Figueiredo, José ⓘ
Departamento de Computación. Universidad Central Marta Abreu de Las Villas.
Villa Clara, Cuba

Pereira Marín, Carlos Alberto ⓘ
Departamento de Computación. Universidad Central Marta Abreu de Las Villas.
Villa Clara, Cuba

Resumen

En el desarrollo de sistemas de información para la gestión de los procesos de negocio de una organización es fundamental la separación entre la lógica del negocio y la lógica del sistema. El enfoque de reglas de negocios ayuda a lograr esta separación y por consiguiente una mejor arquitectura de software. Después de la fase de análisis y captura de las reglas de negocio, el modelado y su automatización son las fases más importantes en el desarrollo de este enfoque. Existen resultados investigativos que aportan variantes de modelados a partir de lenguajes conceptuales de representación, pero no existe un consenso en su automatización para los sistemas de gestión y motores de reglas de negocio. Las ontologías son una vía para la representación del conocimiento en cualquier dominio, su aplicación en los sistemas de información hacia la web semántica es cada vez más sólida. La conceptualización de las reglas de negocio, a partir de su definición ontológica, es una oportunidad para los analistas de negocio de expresar las reglas a su manera y automatizarlas sin necesidad de herramientas adicionales. En este trabajo se expone una extensión de la ontología para la notación del modelado o diagrama de procesos de negocio (BPMNO) de Object Management Group, para expresar o definir reglas de negocio, teniendo en cuenta sus tipos según las clasificaciones más comunes de autores del tema (formalizadas en este trabajo) y los principios para su validación, así como la estructura funcional del BPMNO.

Abstract

By development of information systems for the management of organization's business processes, the separation of business logic and system logic is fundamental. The business rules approach helps to achieve this separation and therefore a better software architecture. After the phase of analysis and capture of business rules, modeling and its automation are the most important phases in the development of this approach. There are research results that provide variants of modeling from conceptual representation languages, but there is no consensus on its automation for management systems and business rules engines. Ontologies are a way for the representation of knowledge in any domain, its application in information systems towards the semantic web is increasingly solid. The conceptualization of business rules, based on their ontological definition, is an opportunity for business analysts to express the rules in their own way and automate them without the need for additional tools. This paper presents an extension of the ontology for the modeling or business process diagram (BPMNO) of Object Management Group, to express or define business rules, taking into account the functional structure of BPMNO, its type according to the most common classifications of authors (formalized in this work) and the principles for their validation.

Palabras Clave:

modelado conceptual, reglas de negocio, procesos de negocio ⓘ

Keyword:

conceptual modeling, business rules, business processes ⓘ

Introducción

La gestión de procesos de negocio es una de las tendencias aplicada a la organización, soportada por muchas metodologías y apoyadas por las tecnologías de la información y la computación. Todo el cambio en la gestión de negocio, pasando del modelo de definición de negocio al modelo de procesos, viene regulado por una serie de normas encaminadas a facilitar la toma de decisiones. Estas normas o reglas de negocio imbuidas en las estructuras empresariales, pueden ser sistematizadas y automatizadas para facilitar las tareas diarias de dirección y control.

Las reglas de negocio son requisitos que definen cómo el negocio debe operar. Según el enfoque de gestión de reglas de negocio, ellas no deben encontrarse embebidas dentro de los procedimientos operativos, sino que se presentan como un componente independiente, pero con un íntimo contacto con los procesos (Stineman, 2009). Esto significa que las reglas de negocio pueden ser activadas, modificadas o desactivadas atendiendo a las necesidades del negocio en un momento dado sin generar cambios en los modelos de proceso de negocio.

La creciente demanda de sistemas de información de tamaño, alcance y complejidad cada vez mayores ha provocado la introducción de varios lenguajes de modelado de alto nivel, mediante los cuales pueden modelarse los requisitos funcionales y no funcionales, así como los componentes del sistema de información a un nivel conceptual.

Las ontologías son modelos que representan una abstracción del dominio de manera formal, un conocimiento estructurado y consensuado entre varias organizaciones o expertos en forma sistemática. En el caso del modelado conceptual del negocio se aplica para la captura de la semántica de las reglas de negocio.

Dado que existe un número relativamente elevado de lenguajes que modelan reglas de negocio dentro de la literatura científica y profesional, se debe decidir por razones prácticas cuál de estos lenguajes se debe seleccionar o crear una nueva formalización para definir las reglas.

El objetivo general de este artículo consiste en mostrar los resultados de una propuesta ontológica para la definición de reglas de negocio, categorizadas según sus posibles invocaciones en un sistema orientado por la gestión de procesos. La estructura de esta definición parte de la ontología para la notación de los diagramas de procesos de negocio de negocio (BPMNO) ylas relaciones con sus elementos (Rospocher, Ghidini, & Serafini, 2014).

Estado del arte

Definición de reglas de negocio

Según Ross (2013), las reglas de negocio han sido descrita a menudo como términos, hechos y reglas. Bajo las rigurosas prescripciones formales de SBVR (siglas en inglés para Semantics of Business Vocabulary and Business Rules), esta descripción no es 100% técnicamente exacto, sin embargo, es memorable y sin duda adecuado para una comprensión inicial.

Una de las definiciones de regla de negocio más citada en la bibliografía consultada por la comunidad dedicada al estudio sobre los temas de gestión de procesos de negocio y reglas de negocio, es la expresada por el padre de las reglas de negocio, Ronald G. Ross, quien la define en la 4ta edición de su libro “Business Rule Concepts” (Ross, 2013), como un enunciado que puntualiza o restringe algún aspecto del negocio. Su intención es afirmar la estructura del negocio, controlar o influir el comportamiento empresarial.

Enfoque de desarrollo de software orientado por reglas de negocio

El enfoque de reglas de negocio propone separar la lógica volátil de las aplicaciones principales para procesarla de manera independiente. Esto facilita la definición y cambio de las reglas y evita la costosa modificación de las aplicaciones legadas. En su artículo, Chaparro_Lemus (2014), presenta un panorama del enfoque de reglas de negocio. Discute las razones por las que este enfoque está siendo adoptado por las empresas que manejan grandes cantidades de reglas volátiles y muestra como el desarrollo investigativo y tecnológico soportan esta tendencia.

Según Ross (2003b), los problemas que aborda el enfoque de reglas de negocio comprende las reglas ad hoc o enfoque lógico y estructurado para la definición de sus reglas de negocio en las organizaciones, también un conjunto claro y bien definido de conceptos brinda una base, sobre la cual pueden apoyarse directamente las reglas, para evitar malas interpretaciones y malentendidos de conceptos claves del negocio. Además, lograr una vía independiente de gestionar las reglas de negocio brinda una accesibilidad directa. Un enfoque basado en reglas, que incluya un rápido desarrollo y despliegue de reglas, ayuda a la diferenciación. Por su parte, la adjudicación, en tiempo real, de la lógica empresarial por los encargados del conocimiento a medida que los errores ocurren, crea un ambiente de autoformación y el conocimiento acumulado en las personas más experimentadas del negocio quede implementado como parte del patrimonio de la organización. Luego, se publicó un documentos titulado “Manifiesto de reglas de negocio”, en el cual se plantean los principios independencia de enfoque de reglas de negocio (Ross, 2003a).

Sistemas de gestión y motores de reglas de negocio. Principios de funcionalidad

Dada la diversidad de herramientas, decidir qué motor seleccionar para implementar el enfoque basado en reglas de negocio es un aspecto importante para su integración en las aplicaciones empresariales. Evidentemente no todos los sistemas de reglas de negocio tienen porque estar construidos sobre una misma arquitectura, pero se han identificado ciertos componentes que tienen los motores de reglas de negocios más populares. Algunos productos generan las reglas de disparadores y procedimientos que van a una base de datos, otros tienen un motor de reglas que las invoca, mientras que otros trabajan orientados a objetos.

Un sistema de gestión de reglas de negocio (acrónimo en inglés: BRMS) se compone de tres elementos básicos: un motor de reglas, encargado de ejecutar las reglas de negocio, un sistema de gestión de la configuración, encargado de almacenar las reglas de negocio utilizadas y una interfaz de acceso para los usuarios que permita la gestión y edición de las reglas de negocio (Figura 1).

Figura 1: Principales componentes de un BRMS (fuente: Fernández_Martínez (2010))

Fernández_Martínez (2010) explica las principales características que debe presentar un BRMS y presenta a una categorización de varios sistemas de código abierto según el algoritmo de ejecución de las reglas, la gestión de la configuración, los roles de usuarios, herramientas de despliegue, validación, lenguaje natural e integración al proceso de desarrollo. Entre los principales resultados se encuentran la homogeneidad de estos sistemas en la aplicación del algoritmo RETE para la ejecución de las reglas, la validación de las reglas y la utilización de lenguajes propios en la implementación. Además la integración en el proceso de desarrollo es costosa y cada adaptación debe ser específica en cada BRMS estudiado.

Por su parte, Faúndes_Gómez, Hitpass, and Astudillo (2011), afirma que los BRMS se han convertido en tecnología clave, al permitir realizar una gestión explícita de las reglas de negocio de manera independiente de las aplicaciones que las utilizan; pero desafortunadamente, es difícil evaluar y comparar las casi 30 plataformas BRMS mainstream en existencia ya que sus proveedores sólo entregan información comercial y muy pocos aspectos técnicos y/o funcionales para poder evaluarlos y categorizarlos.

García_González and André_Ampuero (2015) realiza un análisis comparativo de tres motores de regla de código abierto desarrollados sobre el estándar de Java JSR-94, especificación que define lineamientos y proporciona una API (siglas en inglés para Applications Programming Interface) común para la ejecución de motores de reglas en Java.

Modelado de las reglas de negocio. Lenguajes de reglas de negocio

En su forma más simple, una regla de negocio posee varios parámetros de entrada, una validación entre éstos y de acuerdo a dicha validación, realiza una acción de salida. Todo este modelado debe tener como objetivo el facilitar su implementación dentro de un gestor de reglas de negocio.

El área de modelización y análisis de los requerimientos se caracteriza por la informalidad y la incertidumbre. La calidad de una especificación de estos requerimientos depende en gran medida de la capacidad del desarrollador para extraer y comprender los conocimientos sobre el dominio.

Existen muchos estándares conocidos, en proyectos y también como soluciones, los cuales difieren en la descripción del conocimiento (vocabulario) para los propósitos de los motores de reglas. La mayoría de estas soluciones está desarrollada sobre la base del XML (siglas en inglés para eXtensible Markup Language), pero se han realizado otros trabajos sobre ontologías (OWL) y sobre la notación de BPM (BPMN).

Los resultados de estos trabajos se han distribuido principalmente en las sociedades científicas y sobre algunos dominios particulares, pero que no han alcanzado hasta el momento al mundo empresarial. La mayor dificultad para acceder a esta tecnología radica en la complejidad de los lenguajes propuestos para el usuario final del área de negocios.

Propuesta de clasificación de las reglas de negocio.

Existen muchas y muy variadas clasificaciones de reglas de negocio. Una de las razones para proponer una clasificación es permitir la aplicación de modelos que indiquen el tipo de regla, o sea, poder identificar el tipo de regla aplicada, en todo su ciclo de vida, desde su definición en la fase de análisis y captura hasta su ejecución. Otras de las razones es poder organizar las reglas de manera que puedan usarse los parámetros de clasificación. Además de las anteriores, otro objetivo de la clasificación propuesta en este trabajo es garantizar la inclusión de la mayor cantidad posible de los tipos de reglas de negocio existentes en la literatura, y lograr por esta vía una generalización en la formalización del estándar propuesto como lenguaje de reglas de negocio.

Tipos de las reglas de negocios:

Si se analiza detenidamente los elementos y objetos gráficos de la ontología de la notación del BPM (BPMNO), se puede notar que las reglas de negocio están presente sólo en 3 elementos de la notación. Estos elementos son la actividad o tarea, los eventos y los flujos de secuencia (Figura 2).

Figura 2: Ejemplos de flujos de secuencia asociados a otros elementos de BPMN

Regla de actividad o tarea (BR_Activity): regla de negocio que se ejecuta dentro del marco o límites de una actividad o tarea de cualquier tipo en un proceso de negocio. Esta categoría presenta los siguientes tipos:

Regla de cálculo (BR_Script_Activity): ejecuta algún procesamiento de datos o cómputo sin alterar las propiedades de las entidades del proceso de negocio o de las clases. Los resultados son temporales y se reinician en cada instancia del proceso de negocio.
Regla de datos (BR_Data_Activity): utilizada para realizar cambios en los valores de las propiedades de las entidades del proceso o de las clases ontológicas del dominio. Los resultados son permanentes para cualquier instancia del proceso.
Regla de entrada o salida (BR_InOut_Activity): Es la regla que se activa antes de ejecutar una tarea o luego de haberse cumplido con todas las funciones de la actividad. Puede ser de datos, de cálculo o ambas.

Regla de flujo (BR_Flow): gobierna el comportamiento o flujo en la lógica del proceso de negocio (Figura 4), por lo que se pueden categorizar en:

Regla de flujo sencillo (BR_Simple_Flow): asociada a un flujo de secuencia condicional de una actividad o tarea, que puede cambiar el curso del flujo del proceso cuando se cumpla la condición a consecuencia de los cambios dentro de una actividad o tarea.
Regla de flujo basado en evento (BR_EventBased_Flow): en principio puede cambiar también el flujo del proceso a partir de una actividad, excepto por el hecho que su condición está asociada a la ocurrencia de un evento.
Regla de flujo inclusivo sin compuerta (BR_Inclusive_SimpleFlow): esta regla representa un conjunto de acciones alternativas, cuyas expresiones condicionales de los flujos de secuencia asociados, son completamente independientes entre sí. Básicamente es una agrupación de reglas del tipo “BR_Simple_Flow” (Figura 3).

Figura 3: Componente BPMN para flujo inclusivo sin compuerta.

Regla de flujo basado en compuerta de decisión (BR_GWBased_Flow): es aquella regla de negocio, cuya fuente de salida es una compuerta (Gateway) de decisión de flujo (símbolo de diamante o rombo en figura 4).
- Regla de flujo inclusivo (BR_GW_Inclusive_Flow): en principio tiene la misma funcionalidad que la regla “BR_Inclusive_SimpleFlow”, con la diferencia de que tiene asociada una compuerta de decisión inclusiva (Figura 4).

Figura 4: Especificación de BPMN para flujo inclusivo con compuerta

Regla de flujo exclusivo (BR_GW_Exclusive_Flow): es la regla asociada a la compuerta donde solo es posible una salida. Presenta dos tipos:
- Regla de flujo exclusivo basado en datos (BR_GW_Exclus_DataBased): es la regla asociada a la compuerta exclusiva, donde la evaluación de las expresiones condicionales está basada en datos o propiedades del proceso. La única salida posible es el primer flujo de secuencia, cuya expresión condicional evaluada tome valor verdadero (Figura 5).

Figura 4: Especificación de BPMN para flujo inclusivo con compuerta

Regla de flujo exclusivo (BR_GW_Exclusive_Flow): es la regla asociada a la compuerta donde solo es posible una salida. Presenta dos tipos:
- Regla de flujo exclusivo basado en datos (BR_GW_Exclus_DataBased): es la regla asociada a la compuerta exclusiva, donde la evaluación de las expresiones condicionales está basada en datos o propiedades del proceso. La única salida posible es el primer flujo de secuencia, cuya expresión condicional evaluada tome valor verdadero (Figura 5).

Figura 5: Compuerta de flujo exclusivo para datos en BPMN.

Regla de flujo exclusivo basado en eventos (BR_GW_Exclus_EventBased): el comportamiento de esta regla es similar a la regla BR_GW_Exclus_DataBased, excepto por las condiciones asociadas a los flujos de secuencia, las cuales no existen. La continuidad del proceso depende del tipo de evento y no de expresiones condicionales (Figura 6).

Figura 6: Ejemplo de BPMN para una compuerta exclusiva basada en eventos.

Regla de flujo complejo (BR_GW_Complex_Flow): esta regla representa la situación, donde resulta difícil gestionar las condiciones mediante las compuertas descritas en las reglas anteriores, o sea, cuando es necesario combinar la unión de algunas de ellas en una notación más simple y compacta, o simplemente una expresión compleja para determinar el comportamiento de la compuerta, etc. (Figura 7).

Figura 7: Compuerta de decision compleja en BPMN.

Regla disparadora (BR_Trigger): es la regla aplicada en un determinado momento de la lógica del proceso y fuera de cualquier actividad o compuerta, para poder empezar, continuar o finalizar con el proceso. La condición está determinada por la ocurrencia de un evento. Su implementación depende del tipo de evento y el respectivo disparador de este componente descrito en BPMNO (Figura 8).

Figura 8: Ejemplo de componente de evento para regla de negocio disparadora.

Regla de restricción (BR_Constraint): es la regla de negocio aplicada al dominio de los datos y sus relaciones para garantizar la integridad, la consistencia y la validez de los mismos. Tienen la característica de siempre ser verdaderas.
Regla de inferencia (BR_Inference): es la regla de negocio que deriva una nueva información a partir de la existente, mediante una declaración o sentencia con razonamiento lógico o matemático o ambos.

Estructura de las reglas de negocio. Definición ontológica

La estructura general de las reglas de negocio está basada en la sentencia de la forma IF-THEN (si se cumplen todas las condiciones del IF se ejecutan todas las acciones del THEN), aunque de forma particular existen algunas diferencias al establecer las condiciones y la forma de definirlas, de acuerdo a los elementos ontológicos base relacionados con la regla. En la figura 9 se muestra, de forma general, las relaciones de esta clase con algunas clases pertenecientes a BPMNO para formar parte de la definición de regla de negocio según su categoría.

Figura 9: Vista general de las propiedades objeto o relaciones de la clase “BusinessRule” con algunas clases de BPMNO.

En la siguiente figura se muestra la estructura taxonómica de la clase “Business Rule”, la cual constituye la superclase para la definición de cada tipo de regla, creadas según la jerarquía establecida por los tipos de reglas de negocio adoptados para este estudio (Figura 10).

Figura 10: Taxonomía de la clase “Business_Rule” (fuente elaboración propia).

Regla de actividad o tarea (BR_Activity): es la clase para las reglas que necesariamente se relacionan con la clase “Activity” (de BPMO). En tal sentido se define la propiedad de objeto (object property) “is_BR_executed_in_actitvity” y que tiene como rango la clase “Activity”. Al mismo tiempo se define la relación “has_business_rule” como la inversa de la anterior, con el objetivo de poder identificar a las reglas desde el proceso donde se ejecutan. La restricción de cardinalidad se expresa en la existencia de al menos una tarea o actividad, donde es ejecutada este tipo regla. Dentro de esta clase se definen tres tipos de reglas:

Regla de cálculo (BR_Script_Activity) y regla de datos (BR_Data_Activity): Las estructuras que describen estas dos reglas son similares. Para representar las condiciones de la reglas se define la relación “has_condition” (parte IF de la sentencia IF-THEN), cuyo rango es la clase “Condition”, esta última compuesta de expresiones instanciadas en la clase “Expresión” mediante la relación “has_condition_condition_expression”. La diferencia entre estos dos tipos de reglas radica en las restricciones establecidas sobre el rango de la relación que expresa las acciones “has_assignment_to” (parte THEN de la sentencia IF-THEN). Para la clase “BR_Data_Activity”, los resultados de la regla son permanentes en las propiedades del proceso, de los datos o de las entidades del proceso. Estos cambios son instanciados en los elementos de la clase “Property”, cuyo dominio son instancias de la clase “Data_assignment”, definida como subclase de “Assignment”. En tanto, la clase “BR_Script_Activity” representa la regla de negocio donde los cálculos son resultados temporales, y están instanciados en la clase “BR_Variable”, a partir de la misma relación “has_assignment_to” pero con dominio en “Script_assignment”.
Regla de entrada o de salida (BR_InOut_Activity): a ella está asociada la condición necesaria de pertenecer a la unión de BR_Script o BR_Data para su implementación. La propiedad objeto “has_time_date_rule_expression” es una posibilidad que brinda BPMNO para indicar el momento, expresado mediante fecha y hora o en ciclo, de ejecución de la misma. Un esquema general de la regla de negocio “BR_Activity”, subclases y relaciones se muestran en la figura 11.

Figura 11:Estructura ontológica de las regla de negocio BR_Actitvity, sus subclases y algunas relaciones.

Regla de flujo (BR_Flow): La condición (parte IF de la sentencia IF-THEN) está determinada generalmente en la expresión condicional de un flujo de secuencia, excepto aquella que depende de un evento. En tanto, la acción (parte THEN de la sentencia IF-THEN) que está expresada siempre en la relación “has_BR_sequence_flow_target”, cuyo rango es una actividad, un evento o una compuerta.

Flujo sencillo (BR_Simple_Flow): Esta regla tiene como única propiedad objeto definida “has_BR_sequence_flow”, con rango en la clase “Sequence_Flow” (de BPMNO) y con restricción de ser funcional, o sea, sólo le corresponde una instancia en la clase imagen. El resto de la estructura para esta regla está expresada en los propios atributos de esta relación objeto y los de la clase “Sequence_Flow” (Figura 12).

Figura 12: Estructura ontológica de la regla BR_Simple_Flow.

Regla de flujo basado en evento (BR_EventBased_Flow): su estructura viene dada por las relaciones “has_BR_activity_boundary_intermediate_event” y “is_BR_executed_in_ activity”, asociadas a las clases “activity_boundary_intermediate_event” y “Activity” respectivamente como rangos (Figura 13).

Figura 13: Definición estructural de la regla BR_EventBased_Flow.

Es evidente la necesaria definición de la primera propiedad mencionada, ya que es un evento embebido o adjunto (gráficamente en el borde) de una actividad; sin embargo en la estructura relacional BPMNO de la clase “activity_boundary_intermediate_event” no existe ninguna propiedad que indique a que actividad se halla relacionado el evento, por lo que se define la segunda propiedad para relacionar la actividad asociada al evento en la regla.

Regla de flujo inclusivo sin compuerta (BR_Inclusive_SimpleFlow): como propiedad objeto se define “has_BR_set_of_simple_flow”, la cual indica el conjunto de flujos de secuencia condicionales a esta regla, mediante la asignación de instancias del conjunto de reglas de negocio de la clase BR_Simple_Flow (Figura 14) y con mínima cardinalidad igual a dos (2).

Figura 14: Estructura relacional de la regla de negocio BR_Inclusive_SimpleFlow.

Regla de flujo basado en compuerta (BR_GWBased_Flow): La clase asociada a este componente gráfico es “Gateway” de BPMNO y tiene como propiedad objeto “has_BR_gateway”. Las condiciones y las acciones vienen dadas en las respectivas propiedades de los flujos de secuencia asociados a las puertas de salida (Gate) (mínima cardinalidad es 2) de la compuerta.
- Regla de flujo inclusivo (BR_GW_Inclusive_Flow): la estructura está determinada por la relación “has_BR_gateway”, la cual toma valores solamente en la subclase “inclusive_gateway” de la clase “Gateway”.
- Regla de flujo exclusivo (BR_GW_Exclusive_Flow): es la regla asociada a las compuertas donde solo es posible una salida. Presenta dos tipos de reglas exclusivas (Figura 15):

Figura 15: Estructura y relaciones de la regla BR_GW_Exclusive_Flow

Regla de flujo exclusivo basado en datos (BR_GW_Exclus_DataBased): Como restricción “has_BR_gateway” toma valores solamente en la subclase “data_based_exclusive_gateway” de la clase “Gateway”.
Regla de flujo exclusivo basado en eventos (BR_GW_Exclus_EventBased): en este caso la restricción a “has_BR_gateway” son valores solamente en la subclase “event_based_exclusive_gateway” de la clase “Gateway”. Las condiciones de los flujos de secuencias asociados deben estar configuradas como nulas, pues se trata de esperar que ocurra un tipo de evento.

Regla de flujo complejo (BR_GW_Complex_Flow): está determinada por la restricción de la relación “has_BR_gateway” a las instancias de la clase “Complex_Gateway”, no resulta sencillo establecer las condiciones entrantes y de salida que impone crear instancias de este tipo. Estas propiedades objetos son “has_complex_gateway_

Figura 16: Estructura y relaciones de la regla BR_GW_Complex_Flow.

Regla disparadora (Trigger): la estructura de esta regla está simplemente determinada por la relación “has_BR_event_asociated”, cuyo rango es la clase “event”, donde son especificados los tipos de eventos que pueden ocurrir en un proceso y los detalles de los respectivos “disparadores” que los activan.
Regla de restricción (Constraint): No es necesario definir esta regla directamente en el modelado conceptual, ya que se especifica mediante declaraciones de lógica descriptiva en la definición de las restricciones de las clases, las propiedades y las relaciones de la ontología de dominio del problema o negocio.
Regla de inferencia (Inference): Al igual que la regla de restricción, esta es implementada fuera de la definición conceptual, pero mediante el lenguaje SWRL, dándose la posibilidad según el editor ontológico utilizado para crear este tipo de regla.

Conclusiones

A partir de las correspondencias establecidas entre la categorización propuesta y los tipos de reglas de negocio más comunes, según las interpretaciones y definiciones expresadas en la bibliografía consultada, se puede observar el amplio abanico de inclusión que puede abarcar esta clasificación; sin que se pierda en significado que le da el nombre a la categorización.
Los lenguajes de modelado de reglas de negocio apuntan hacia el futuro tecnológico para el apoyo a los esquemas de automatización de alto nivel para los requisitos del usuario.
La posibilidad de exportar la ontología a diferentes formatos, y en particular a formato de tripletas (TDB, TURTLE, N3, etc.), permite la creación automática de un lenguaje de reglas de negocio, que puede ser accesible a partir del lenguaje de consulta SPARQL.
No es intención sustituir las clasificaciones establecidas, simplemente es una opción de extensión del BPMNO para aquellos sistemas basados en ontologías y sin recursos de definición de reglas de negocio. Con un formalismo de este tipo, los usuarios de sistemas orientados a reglas de negocios pueden definir sus propias reglas y crear traductores "de acuerdo al motor de destino para una completa autonomía de cualquier proveedor.