Ontology based Framework for the description and validation of business processes

Nemury Silega^I, Tania Teresa-Loureiro^I, Manuel-Noguera^II, Juan Pedro-Febles^I

^IUniversidad de las Ciencias Informáticas, Habana, Cuba
^IIUniversidad de Granada, Departamento de Lenguajes y Sistemas Informáticos, Granada, España

RESUMEN

Los sistemas de gestión empresarial son muy complejos y de gran magnitud, encargados de gestionar integradamente los procesos de una empresa. Estas características determinan que la fase de modelado de los procesos que componen el sistema adquieraun papel fundamental, es tan importante la descripción como la validación de los procesos porque los errores que no se detecten en esta fase tendrán un impacto negativo en las fases subsiguientes y por ende en la calidad final del sistema. En este trabajo se aborda la descripción y validación de procesos de negocio de gestión empresarial a partir de un framework que combina algunas de las tecnologías de mayor aceptación en la comunidad de desarrolladores e investigadores del software. El framework está basado en el paradigma de Arquitectura Dirigida por Modelos y es complementado con el uso de ontologías las que aumentan las posibilidades de validar semánticamente los procesos de negocio.

Palabras clave: procesos de negocio, sistemas de gestión empresarial, ontologías, arquitectura dirigida por modelos. 

ABSTRACT

Enterprise management systems are very complex and big, who manage integrally business processes of an enterprise. These characteristics state that the processes modeling phase that compose the system play a relevant role. Both the description and validation of processes are very important because undetected mistakes in this phase will have a negative effect in the upcoming phases and in the final system quality. This paper deals with description and validation of enterprise management process through a framework that combine some technologies that have great acceptation in both   software researchers and developers. The framework is based on the paradigm of Model Driven Architecture and is complemented with ontologies which raise the possibilities to semantically validate the business processes.

Key words: business processes, enterprise management systems, ontologies, Model Driven Architecture.

INTRODUCCIÓN

Existen diversas propuestas para la descripción de procesos de negocio dentro de las que se destacan BPMN, UML, IDEF0 y otras notaciones o lenguajes. Sin embargo, estas propuestas se enfocan principalmente en ofrecer elementos que garanticen que se pueda representar cualquier proceso de negocio y no abordan aspectos propios de ciertos dominios. Con las propuestas actuales es imposible incluir restricciones o propiedades propias del dominio de los sistemas de gestión empresarial. Con esta situación resulta imposible realizar validaciones semánticas a los procesos descritos lo que influye en la calidad y adaptabilidad de los sistemas de gestión empresarial.

En este trabajo se presenta un framework que utiliza BPMN y la complementa con una ontología. Con esta propuesta se podrá describir los procesos de gestión empresarial, además se podrá realizar una validación semántica de los procesos ya que en la ontología se recogen elementos propios que caracterizan la gestión empresarial y que enriquece su descripción. Por otra parte, el uso de una ontología permitirá el razonamiento automático sobre los modelos descritos así como poder compartir e intercambiar la descripción de los procesos los que pueden ser analizados por otras herramientas o sistemas inteligentes. 

El artículo está organizado de la siguiente forma: en la sección 2 se analizan algunos trabajos que abordan la misma problemática. En la sección 3 se describen algunas de las tecnologías en los que se basa la propuesta que se presenta en la sección 4. Finalmente, en las secciones 5 y 6 se presentan las líneas de trabajo futuro y conclusiones.

MÉTODOS

En (Rolán, Ruiz, Rubio, & Piattini, 2005), se realiza una propuesta de evaluación de procesos de negocio realizando una adaptación y extensión del marco FMESP (Framework for the Modeling and Evaluation of Software Processes). En esta propuesta se utiliza la notación de modelado BPMN y el objetivo con la definición y la validación de las métricas en FMESP es determinar un grupo de indicadores útiles para la mantenibilidad de los modelos de proceso software evaluando su complejidad estructural. Pese a que es muy útil contar con los indicadores que se proponen, la métrica se centra sólo en ofrecer una medida cuantitativa de la complejidad estructural de los modelos de procesos de negocio y no aborda la manera de determinar la calidad de la descripción del proceso. Con los elementos ofrecidos en esta propuesta no se puede determinar si la descripción de un proceso es correcta.

En la investigación presentada en (Bonillo, 2006) proponen una metodología para la gerencia de procesos sustentada en el uso de patrones de software que cuenta con dos macro-procesos: la creación del proceso y la administración del proceso, este último cuenta con la actividad validación de los datos técnico-funcionales de los procesos implementados a través de indicadores de gestión. Sin embargo, estas actividades y en especial la que nos interesa, no se encuentran descritas de forma tal que ofrezcan una idea clara sobre qué se realiza en cada una de ellas. Por lo tanto, no podemos realizar una valoración objetiva del proceso de validación. Además, esta metodología está basada en cualquier tipo de procesos lo que hace muy difícil que se puedan definir elementos para la validación semántica de dichos procesos.

En el trabajo (Díaz-Montenegro Quesnel, 2009) se realiza un estudio para proporcionar una  metodología de diseño como un conjunto de técnicas, recomendaciones y verificaciones, que permitan  sistematizar la modelización de proceso. En dicho trabajo proponen una guía para realizar el diseño de los mapas de procesos. En dicha guía conciben un paso denominado Verificación del diseño, el cual cuenta con cinco reglas para verificar la bondad del diseño. Sin embargo, estas reglas sólo chequean aspectos muy específicos vinculados con la metodología que se propone por lo que no tienen validez si se usa otra metodología para la descripción de los procesos de negocio.  Esta guía está enfocada al diseño de nuevos procesos mientras que nuestro trabajo se enfoca en la descripción de procesos bien definidos. Por otra parte, en este trabajo no se le ofrece relevancia a la validación semántica de los procesos, influenciado por la generalidad de la propuesta.

El objetivo de la tesis doctoral "Definición de un modelo para la verificación formal de procesos de negocio" descrita en (Fisteus, 2005) , es realizar aportes en los ámbitos de la verificación de requisitos funcionales de procesos de negocio y composiciones de servicios Web. Proponer una arquitectura de verificación más abierta, modular y extensible, en dicha arquitectura pretende adaptar las definiciones de procesos de negocio con el objetivo de que sean verificables mediante distintas herramientas de verificación desarrolladas previamente en el ámbito de los métodos formales. Se identifican un conjunto de restricciones para la modelación formal común de un proceso, además se aplican herramientas para la verificación de procesos de negocio. Como se centran en la formalización de cualquier proceso de negocio resulta difícil realizar validaciones específicas de procesos de un dominio específico.

Este hecho pone en peligro la calidad de las actividades que le siguen a la modelación de los procesos que incluso pueden hacer que el proyecto no cumpla todas las expectativas de los clientes para los que se realiza el sistema y el proyecto fracase. Teniendo en cuenta estos elementos en la sección 4 se describe una propuesta que puede constituir un paso importante en la validación semántica de procesos de negocio de gestión empresarial.

Tecnologías bases del Framework

En esta sección se describen algunas tecnologías que constituyen la base de la propuesta. Se especifican los principales conceptos de MDA, BPMN y Ontologías.

Arquitectura dirigida por modelos (MDA)

MDA es una propuesta promovida por el Object Management Group (OMG, por sus siglas en inglés), en (OMG, 2003) se describen las ideas fundamentales de este paradigma y se define como una propuesta para el desarrollo de sistemas y que es dirigido por modelos porque provee los recursos para que los modelos dirijan el curso del entendimiento, diseño, construcción, despliegue, operación, mantenimiento y modificación de los sistemas.

MDA pretende obtener aplicaciones con alta flexibilidad en la implementación, integración, mantenimiento y prueba. Los tres principales objetivos de MDA son: portabilidad, interoperabilidad y reusabilidad. Propone tres puntos de vistas para un sistema: punto de vista independiente de la computación, punto de vista independiente de la plataforma y punto de vista específico de la plataforma.

Un Modelo Independiente de la Computación (CIM): es una vista de un sistema independiente de la computación. No muestra detalles de la estructura del sistema y juega un papel fundamental en salvar la brecha entre los especialistas funcionales especialistas en el desarrollo de software.

Un Modelo Independiente de la Plataforma (PIM): es una vista del sistema independiente de la plataforma. Brinda la posibilidad de usar diferentes plataformas para implementar un sistema.

Un Modelo Específico de la Plataforma (PSM): es una vista de un sistema con las especificaciones de la plataforma. Un PSM combina las especificaciones en los modelos independientes de la plataforma con los detalles de cómo el sistema usa ciertos elementos de una plataforma específica.

El otro elemento importante en MDA es la transformación de los modelos, que es el proceso de convertir un modelo a otro del mismo sistema y pueden estar a diferentes niveles de abstracción. Uno de los principales empeños de la comunidad de investigadores en este momento es lograr que la transformación entre modelos se realice de la forma más automatizada posible y que se pueda garantizar la consistencia entre los modelos origen y destino.

Modelado de Procesos de negocio

Existen varios lenguajes o métodos para modelar procesos de negocio, entre los que se encuentran: Métodos para el modelado funcional (IDEF0), Lenguaje Unificado para la construcción de Modelos (Lazar, S. Motogna, & Párv, 2010), Notación para el Modelado de Procesos de Negocio (BPMN), entre otros. En los últimos tiempos BPMN ha emergido como el preferido porque define una notación fácilmente entendible tanto por todos los involucrados como por el equipo de desarrollo (OMG, 2009).

Un componente esencial en BPMN es el diagrama de procesos de negocio (BPD), el cual es usado para crear modelos gráficos de procesos de negocio. Los elementos fundamentales de un BPD descritos en (White, 2004) son: Objetos de flujo, Objetos de conexión, Líneas de vida y Artefactos.

En la propuesta que se presentará en la sección 4 se plantea comenzar el modelado de procesos mediante un BPD, además se presenta un nuevo modelo el cual está inspirado en los BPD.

Un tema que es necesario mencionar es que BPMN no posee una semántica formal, lo que conlleva a que sea necesario complementarlo con algún lenguaje formal. En este caso puede ser de ayuda el uso de ontologías.

Ontologías

En (Noy  & McGuinness, 2001) se define ontología como: Una descripción formal explícita de los conceptos (clases) en un dominio de discurso, las propiedades de cada concepto que describen sus rasgos y atributos y las restricciones.

Existen varios lenguajes para especificar ontologías, dentro de los que se destacan: Ontolingua, XML Schema, RDF (Resource Description Framework), RDF Schema (o RDF-S), OWL (Xing & Ah-Hwee) y otros. Dentro de todos, se distingue OWL por las facilidades que brinda y dentro de las que sobresale su conjunto de operadores: intersección, unión y negación (Horridge, 2009). Está basado en un modelo lógico que le permite definir los conceptos tal y como son descritos. Además, la posibilidad de utilizar razonadores permite chequear automáticamente la consistencia de los modelos representados. Las ventajas descritas y la posibilidad de contar con la herramienta Protégé que permite crear ontologías de manera sencilla en OWL y utilizar razonadores, han determinado que en esta propuesta se asuma OWL como el lenguaje para la representación de ontologías.

RESULTADOS

Descripción y validación semántica de procesos de negocio de gestión empresarial

Un Diagrama de Procesos de Negocio (BPD) ofrece facilidades para describir cualquier proceso de gestión empresarial desde una perspectiva del cliente y que pueda contar con casi todos los elementos que caracterizan un entorno de gestión empresarial. Sin embargo, existen informaciones imposibles de capturar. Por ejemplo, existen ciertas restricciones vinculadas con los tipos de actividades que no pueden ser verificados en un BPD. Una muestra puede ser la precedencia de actividades, por ejemplo, está establecido que luego de contabilizar un pago anticipado, este no se puede eliminar. Sinembargo, en un BPD se puede modelar este escenario sin que se reconozca como un error, como se muestra en la figura 1. El recuadro marcado resalta el erro descrito. 

En la siguiente sección se presenta una propuesta que tiene en cuenta una serie de definiciones relacionadas con la gestión empresarial. Además, para evitar las nefastas consecuencias que podrían provocar errores como el que se describió se complementa el BPD con una ontología.

Conceptos de la gestión empresarial

Existen dos conceptos básicos para caracterizar un entorno de gestión empresarial: elementos patrimoniales y cuentas. Por la relevancia para la propuesta a continuación se describen estos dos conceptos:

Los elementos patrimoniales son el conjunto de bienes, derechos y obligaciones, pertenecientes a una empresa y que constituyen los medios económicos y financieros a través de los cuales ésta puede cumplir sus objetivos. En una empresa cualquiera de las que conocemos el objetivo último que persigue es la obtención del máximo beneficio posible.

Un sistema de gestión empresarial debe ser capaz de gestionar los elementos patrimoniales y las cuentas de la empresa. Además, incluimos otro término que ayuda a organizar un sistema, nos referimos a elemento del dominio y elemento de usuario.

 Generalmente a un sistema de gestión empresarial se le incluyen requisitos generales, los cuales generan actividades que no coinciden con las actividades propias del negocio de las empresas. Un ejemplo de un requisito general puede ser que todas las operaciones de la empresa se puedan efectuar en varias monedas, este requisito genera que cada vez que se vaya a ejecutar una operación se verifique la tasa de cambio de las monedas. Otro ejemplo podría ser que el sistema debe permitir que se pueda gestionar los recursos de varias entidades. Estos requisitos imponen restricciones al sistema y se les denominan elementos del dominio por su analogía con los elementos patrimoniales, su función fundamental es proveer de los elementos necesarios para que se puedan gestionar los elementos patrimoniales y se cumplan los requisitos generales del sistema.

Otro de los conceptos propuestos por analogía es elementos de usuario los que se refieren al conjunto de acciones que realizan los trabajadores en una empresa que no generan un cambio en los elementos patrimoniales o de dominio, por ejemplo la revisión de un expediente o el envío de un correo. Más adelante, en los términos de un sistema estos elementos de usuario generarán interfaces de usuario. En el texto cuando se utilice sólo el término elementose estará generalizando los elementos patrimoniales, de dominio y de usuario que para ciertos escenarios tienen igual comportamiento.

Además de los conceptos descritos hasta el momento, a continuación, se describen otros que son de menor complejidad. El concepto actividad en uno de los básicos para la descripción de un proceso de negocio de gestión empresarial (PNGE). Los procesos de distintos dominios se diferencian por los tipos de actividades que ejecutan. Específicamente las actividades de los procesos de gestión empresarial se puedan clasificar en tres grupos: las que se encargan de variar el estado de los elementos patrimoniales de la empresa, las que se encargan de variar el estado de los elementos de dominio y las actividades realizadas que no cambian el estado de algún elemento patrimonial o de dominio.

Un ejemplo del primer tipo de actividad es el ingreso en la empresa de un nuevo producto o el reconocimiento de un nuevo derecho de cobro o una nueva obligación de pago. Un ejemplo del segundo tipo de actividad es cuando se inserta una nueva moneda o se actualiza la estructura organizativa de la empresa. El tercer tipo de actividad no genera cambios en los recursos de la empresa, por ejemplo, revisar el expediente de un cliente o un proveedor.

Concreta y semánticamente, una actividad es la ejecución de un tipo de actividad sobre un elemento. Para cada elemento se identifican todos los tipos de actividades que se pueden ejecutar, esta asociación debe tener sentido para el negocio, por ejemplo un derecho de cobro se puede insertar, liquidar, eliminar, contabilizar, entre otros tipos de actividades. Sin embargo, no tiene sentido para el negocio que un derecho de cobro se arquee, por lo que si en la descripción de un PNGE se encuentra este escenario se debe reconocer como un error.

Objeto es otro de los conceptos importantes dentro de la descripción de un PNGE. Se refiere al instrumento o documento físico donde se almacena la información generada en una actividad. Usualmente en un PNGE se genera al menos un objeto.

Teniendo en cuenta todas las definiciones anteriores se puede concluir que un PNGE es el conjunto de actividades con un objetivo determinado. Que en este caso el objetivo de cualquier PNGE es registrar la evolución de los recursos de una empresa.

Restricciones Semánticas

1. No pueden existir actividades iguales consecutivas.

2. Una actividad x no puede estar 2 veces sucedidas por la actividad y.

3. En todo proceso se debe realizar alguna contabilización (Realizar el tipo de actividad contabilizar sobre algún elemento patrimonial).

4. No pueden existir dos actividades de dominio consecutivamente.

5. No se puede violar el orden de precedencia de los tipos de actividades sobre un elemento patrimonial.

6. No pueden efectuarse los tipos de operaciones obre un elemento patrimonial si no se definió previamente.

Además de las restricciones semánticas identificadas se deben comprobar las restricciones sintácticas de un proceso de negocio, estas restricciones se detallan en (White, 2004). Además, es válido aclarar que la identificación de restricciones semánticas para un PNGE no es el objetivo fundamental de este trabajo. El objetivo que se persigue es demostrar que con el framework que se propone se pueden describir los procesos incorporándole toda la información necesaria para que se pueda realizar la validación semántica.

Modelos para la descripción y validación de un PNGE

En la sección 3.1 se detallaron las ventajas del paradigma para el desarrollo de software MDA. Por esas notables ventajas se sigue en esta propuesta dicho paradigma, específicamente nos centramos en el nivel CIM. A continuación, se describen los modelos que componen ese nivel.

BPMN es reconocido como una de las propuestas de mayor aceptación para modelar una vista del funcionamiento de una empresa. Teniendo en cuenta las ventajas que se mencionaron en la sección 3.2 se propone partir de la descripción de los procesos utilizando BPMN, específicamente se debe obtener un BPD. No obstante, se debe tener en cuenta las especificaciones ofrecidas en la sección anterior, para ello es recomendable seguir los siguientes pasos:

• Identificar los elementos patrimoniales.
• Identificar los elementos de dominio.
• Identificar los elementos de usuario.
• Identificar todas las acciones que se le pueden realizar a cada elemento.
• Asegurarse que alguna de las actividades se debe contabilizar en cada proceso.
• Realizar correctamente la secuencia de actividades que conforman el proceso y que no violen el orden de precedencia establecido.

Al finalizar estos pasos se contará con la descripción de un PNGE que tiene en cuenta las definiciones semánticas mencionadas. No obstante, BPMN es una notación semi-formal por lo que es difícil realizar validaciones semánticas de los modelos siguiendo esa notación. Además, en un BPD existen algunos conceptos importantes que no pueden ser tenidos en cuenta explícitamente (elementos, tipo de actividades y otros elementos descritos en la sección 3.1). Esto determina que sea necesario expresar el modelo descrito en algún lenguaje con una semántica formal y se pueda incluir la información necesaria para la validación semántica y automatizada de un proceso de negocio. Con ese fin las ontologías constituyen una propuesta recomendable.

En la sección 3.3 se mencionaron algunas de las ventajas de las Ontologías, por ello se seleccionó como solución a la validación semántica. Para lograr describir un proceso de negocio se definieron como clases cada uno de los conceptos descritos en la sección 3.1, además los conceptos que define BPMN para los diagramas de procesos de negocio, las clases son las siguientes: Elemento, ElementoPatrimonial, ElementoDominio, ElementoUsuario, ElementoRegistro, Actividad, TipoActividad, SuperTipo, Objeto, Estado, Evento, Decision.

OWL no ofrece constructores nativos para la descripción de procesos, por ello es necesario declarar algunas clases que permitan hacerlo, en este caso tenemos las siguientes clases: Paso,PasoInicio, PasoFin. Esta propuesta se basa en la presentada en (Noguera, 2009). La clase Paso es una clase abstracta que se necesita para incluir las clases Actividad,Evento y Decision que son las operaciones que se pueden ejecutar en un paso dentro del flujo del proceso.

En la Ontología también se incluyen propiedades que permiten modelar las relaciones entre los diferentes conceptos. Estas propiedades obedecen a representar las relaciones descritas en la sección 3.1 y las relaciones propias entre los conceptos de BPMN. Algunas de las propiedades más importantes son:

• Un proceso tiene varios pasos.
• En cada paso se puede ejecutar una decisión, una actividad o un evento.
• Cada actividad tiene un tipo de actividad y se realiza sobre un elemento.
• Un proceso comienza con un paso de inicio y termina con un paso fin.

Además, en la Ontología se incluyen propiedades que permiten verificar las restricciones abordadas en la sección 3.1.

Para chequear la restricción 2 se incluyó en la ontología la propiedad Es Adyacente Varias Veces. La definición de esta propiedad también se realizó con SWRL. Además, se incluyó una clase denominada ActividadesIncorrectas. Esta clase se definió como equivalente y contendrá todas las actividades que violen la restricción2. Para ilustrar estas definiciones, se definió en la ontología que las actividades Activity3 y Activity5son iguales, las actividades Activity4 y Activity6 también son iguales. Además, la actividad Activity3 es seguida por Activity4 y Activity5es seguida por Activity6. Con estas definiciones el razonador debe identificar estas actividades como incorrectas. La figura 2 muestra ese razonamiento.

Con el objetivo de verificar el cumplimiento de la restricción 3 se incluyeron en la ontología algunas especificaciones. Primero, se particularizó el tipo de actividad contabilizar, para ello se creó el tipo TipoNucleo. Además, a la clase Proceso se le definió como condición necesaria que todo proceso debe tener al menos una tarea donde se contabilice un elemento patrimonial. Esta especificación se muestra en el recuadro marcado en rojo en la figura 3.

Para ilustrar lo explicado se definió en la ontología que el Proceso Proceso1 tiene la actividad act1 la cual es una actividad de dominio. Cuando el razonador analiza la ontología chequea que exista alguna actividad que contabilice un elemento patrimonial. En este caso existe una sola actividad y referencia a ElementoDominio1, que es un elemento de dominio. No obstante, es necesario especificar que el proceso tiene exactamente una actividad, con el fin de "cerrar" el dominio. Por lo tanto, para que el modelo esté correcto ElementoDominio1 debe ser un elemento patrimonial y ya está especificado como un elemento de dominio. Sin embargo, ElementoDominio y ElementoPatrimonial son clases disjuntas. Esto determina que el razonador no encuentre ningún modelo que satisfaga la condición de que un individuo pertenezca a las dos clases simultáneamente. Por ello lanza una excepción, como muestra la figura 4. 

Pero no es suficiente con especificar que se haga referencia a un elemento patrimonial. Por ejemplo, se cambió la declaración de Act1, se especificó que referencia a Elemento Patrimonial 1 que es un elemento patrimonial. Además, se declaró que Act1 tiene tipo Tipo1. En un primer momento el razonador no detecta la inconsistencia porque aunque Tipo1 no es declarado como un TipoNucleo no se puede asumir que no lo es. Sin embargo, al definir explícitamente que Tipo1 no es un TipoNucleo, el razonador detecta la inconsistencia, como se muestra en la figura 5.

Para asegurarnos que no se viole la restricción 4, se definió que si una actividad de dominio es adyacente a otra actividad de dominio, se clasifiquen como actividades incorrectas, como se muestra en la figura 6 a). En la figura 6 b) se muestra cómo el razonador dedujo que la actividad 9 es incorrecta. Esta inferencia es porque se estableció que la Activity 8 es de dominio y es seguida por la Activity 9 que es también de dominio.

Para verificar la restricción 5 se realizaron varias definiciones en la ontología. Primero se estableció un orden de precedencia de los tipos de actividades, por cada tipo se definió los tipos que pueden sucederlo o precederlo. Las propiedades EsSucesorDeTipo y EsPrecedenteDeTipo permiten gestionar esa información. Además, fueran especificadas en la ontología las propiedades EsPresedenteDeActividad y EsSucesoraDeActividad, las que permitirán conocer todas las actividades que le suceden y preceden a cualquiera actividad en un proceso. Después de estas definiciones se especificó que si una actividad es sucedida por otra cuyo tipo debe ser antecesor, entonces esas actividades tienen errores de precedencia. La propiedad TieneErroresDePrecedenciaCon identifica las actividades que poseen errores de precedencia, igualmente esta propiedad se definió con SWRL debido a su complejidad.

Para ejemplificar lo explicado, en la ontología se definió que Actividad 11 sucede a Actividad10. Además, Actividad 10 y Actividad 11 tienen como tipo a Tipo7 y Tipo5 respectivamente. En adición, se especificó que Tipo7 debe ser sucesor de Tipo5. Por lo tanto, se reconoce que existe un error de precedencia entre las actividades Actividad 10 y Actividad 1. En la figura 7 se muestra la verificación de la restricción.

Para ilustrar la efectividad de estas especificaciones se definió en la ontología que al elemento Elemento 3 se le puede realizar el tipo Type 7. Por otra parte, se estableció que la actividad Activity13 referencia al elemento Elemento1 y tiene como tipo Type5. Como Type5 no está dentro de los que puede realizársele a Elemento1el razonador infiere que Actividad13 es Actividad Incorrecta Con Tipo Tipo 5. La figura 8 ilustra lo explicado.

Transformación BPMN a Ontología

En las secciones anteriores se abundó sobre los beneficios que brinda tener descrito un proceso de negocio tanto en BPMN como en una ontología. Pero es conveniente que la persona que modele el proceso no tenga que hacerlo dos veces, una para cada tecnología. Además, se cumple con una de los empeños más relevantes de MDA,obtener un modelo a partir de otro. Se partirá del BPD y se transformará a la Ontología. En la tabla 1 se muestran las reglas de transformación entre los conceptos de ambos metamodelos.

Con la transformación del BPD a OWL se garantiza que el modelador sólo realice de forma manual el BPD. Sin embargo, es necesario agregar algunas informaciones que completen la descripción del PNGE y se pueda validar las restricciones descritas en la sección 4.1. En la sección 4.4 se describe el mecanismo de agregar esta información a la ontología y donde se sigue también las reglas de transformación mostradas en la tabla 1.

DISCUSIÓN

Plugin al Protégé para la transformación de modelos. Caso de estudio

En la figura 9 se muestran todas las funcionalidades del plug-in. Este plug-in está diseñado para ofrecerle soporte a un método de desarrollo basado en MDA, no obstante para el ámbito de este trabajo solo se explica la funcionalidad importar, las cual se encarga de transformar un BPD expresado en formato XMI a un ontología, siguiendo las reglas de transformación presentadas en la tabla1.  En la figura 9, se muestra una vista del plug-in donde se cargan todas las actividades del BPD y se le incorporan algunas informaciones necesarias para la validación, en este caso se trata de explicitar el elemento al cual la actividad referencia y el tipo de actividad que es.

Después de completar la información de cada una de las actividades y agregarlas a la tabla de la derecha, se presiona el botón aceptar, como muestra la caja de texto 4 de la figura 10.  Luego, automáticamente se actualizará la ontología, la figura 11 muestra las actividades del BPD que fueron transformadas en individuos de la clase actividad en la ontología.

Una vez actualizada la ontología con los elementos del BPD, es posible validar el proceso. En este caso, el proceso presenta el error referente a la actividad eliminar pago anticipado la cual no debe suceder a la actividad contabilizar pago anticipado. Al ejecutar el razonador, se detectará un error de precedencia y se ofrecerá un razonamiento como el mostrado en la figura 7. Cada una de las restricciones se podrá verificar de la misma manera que se explicó en la sección 4.3.2. Con estos pasos se detectarán errores durante el modelado de procesos de negocio, si estos errores no son detectados pueden traer consecuencias muy negativas para el sistema a desarrollar, por lo que esta propuesta se puede considerar de gran utilidad.

En este trabajo se ha abordado la descripción y validación de procesos de negocio de gestión empresarial. Pese al gran impacto que puede tener la propuesta, esta constituye sólo un paso dentro de una propuesta más abarcadora que permita alcanzar un método desarrollo de software dirigido por modelos que abarque todo el ciclo de desarrollo. Por ello, algunos de los temas en que es necesario enfocarse a partir de ahora son:

• Desarrollar los metamodelos para la especificación de los modelos independientes de la computación.
• Extender la ontología para que permita la validación de los modelos independientes de la plataforma.
• Determinar las reglas para la transformación de CIM a PIM.
]]> Extender el plug-in para que ofrezca soporte a los modelos independientes de la plataforma y su transformación.
• Extender la ontología para verificar otras restricciones semánticas en procesos de negocio de gestión empresarial. 

CONCLUSIONES

En este trabajo se examinaron los aspectos fundamentales de un marco de trabajo cuyo fin es mejorar la descripción de procesos de negocio y permitir la validación semántica de los mismos. Este framework sigue las definiciones del paradigma de desarrollo de software dirigido por modelos. Específicamente en este trabajo se describieron los modelos independientes de la computación y se continúa trabajando para extender el framework de forma tal que abarque también los modelos independientes de la plataforma. En el trabajo se describen una serie de conceptos propios de la gestión empresarial que deben ser tenidos en cuenta a la hora de describir los procesos, lo que permitirá modelos más enriquecidos y cercanos a la realidad.  Un diagrama de procesos de negocio siguiendo la notación BPMN es el primero de los modelos propuestos, pero se ofrece una guía para que en este se tengan en cuenta los conceptos de la gestión empresarial identificados. Además, se identificaron algunas restricciones semánticas en los procesos de gestión empresarial. Estas restricciones no pueden ser detectadas en un BPD porque BPMN no es una notación formal. Este hecho motiva a la transformación del BPD a una ontología, lo que permite validar automáticamente la descripción del proceso de negocio. Con el fin de lograr que la propuesta sea aplicable, se desarrolló un plug-in que ofrezca soporte a las definiciones propuestas. Gracias a este plugin el proceso se realiza semi-automáticamente, logrando vencer uno de los principales retos de MDA. Con la exposición de algunos ejemplos se pudo demostrar la calidad y aplicabilidad de la propuesta, así como su utilidad, no obstante, se continúan dando pasos para extender la solución.

REFERENCIAS

1.  Blanco ER. Contabilidad y fiscalidad. 2008. Citado 24 de junio 2012. Disponible en: www.eumed.net/libros/2008b/396/

2.  Bonillo P. Metodología para la gerencia de los procesos del negocio sustenda en el uso de patrones. Journal of Information Systems and Technology Management. 2006;3(2):143-62.

3. Díaz Montenegro Quesnel S. Metodología de definición de procesos. Madrid, España: Universidad Politécnica de Madrid; 2009.

4.  Fisteus JA. Definición de un modelo para la verificación formal de procesos de negocio. España: Universidad  Carlos III de Madrid, Leganés; 2005.

5. Horridge M. A Practical Guide To Building OWL Ontologies Using Protégé 4 and CO-ODE Tools. 1.2 ed. Manchester: The University Of Manchester; 2009.

6. Lazar IS, Motogna P, B. Behaviour-Driven Development of Foundational UML Components. Electronic Notes in Theoretical Computer Science. Theoretical Computer Science. 2010:91-105.

7. Molina JG, Sánchez Cuadrado J, Velasco JL. Una experiencia en transferencia de tecnología de desarrollo  de software dirigido por modelos. En: Paper presented at the XIV Convención y Feria Internacional Informática.  

8. Noguera M. Modelado y análisis de sistemas CSCW siguiendo un enfoque de ingeniería dirigida por ontologías Universidad de Granada; 2009.

9. Noy  NF, McGuinness DL. Ontology Development 101: A Guide to Creating Your First Ontology. SMI-2001-0880. Stanford: Stanford Medical Informatics. 2001.

10. OMG. MDA Guide Versión 1.0.1. 2003.

11. OMG. Business Process Model and Notation (BPMN). Versión 1.2: OMG; 2009.

12. Rolán E, Ruiz F, Rubio FAG, et al. Aplicación de métricas software en la evaluación de modelos de procesos de negocio. Revista Sociedad Chilena de Ciencia de la Computación. 2005;6(1).

13. Pan JZ, Oberle D, Wallace E, et al. Ontology Driven Architectures and Potential Uses of the Semantic Web in Systems and Software Engineering. 2006.

14. White SA. Introduction to BPMN; 2004.

15. Xing J, Ah Hwee T. CRCTOL: A semantic-based domain ontology learning system. Journal of the American Society for Information Science & Technology. 2010;61(1):150-68.

Recibido: 24 de marzo de 2013. ]]> Aprobado: 3 de julio de 2017.

Nemury Silega, Universidad de las Ciencias Informáticas, Habana, Cuba
Correo electrónico: nsilega@uci.cu

[1] Dos de los autores son desarrolladores del ERP CEDRUX