Articulo Congreso Andino LOC PDF

Enfoque para Flexibilizar el Modelo de Proceso de Negocio
[More flexible approach to Business Process Model]

1
Luis Oliverio CHAPARRO LEMUS
2
Ponencia
Eje temático: Ingeniería de Software Temática: Automatización de Procesos
Resumen
Los Sistemas de Gestión de Procesos de Negocio (BPMS) tienen por objetivo facilitar la actividad
empresarial, permitiendo el control automatizado de los procesos de las organizaciones. Sin
embargo, no es deseable que los modelos de proceso de negocio, generados por estos BPMS,
incluyan las reglas de negocio dentro de sí. Esto representa un serio problema para la
modularidad y flexibilidad del modelo, pues cuando se requiere modificar una regla que se usa en
distintos puntos del modelo, es necesario modificar el modelo en todos los puntos donde se utilice
la regla. En este artículo se hace una propuesta para separar las reglas de negocio del modelo de
proceso y manejarlas de forma independiente mediante un motor de reglas de negocio. Esto
implica guardar las reglas de negocio en un repositorio que controla un motor de reglas de negocio
y una técnica para invocar la regla desde el modelo. Con este trabajo se hace un aporte al
mejoramiento del diseño de los actuales BPMS que se traduciría en modelos de negocios muy
flexibles y modulares.
Palabras Claves: Regla de negocio, Motor de Reglas de Negocio, Proceso de Negocio, Modelo
de Proceso de Negocio, Suite de Gestión de Procesos de Negocio (BPMS).
Abstract
Systems Business Process Management (BPMS) are intended to facilitate business, allowing
automated control of the processes of organizations. However, it is not desirable that the business
process models generated by these BPMS, business rules included within. This presents a serious
problem for modularity and flexibility of the model, because when you want to change a rule that is
used in different parts of the model, it would be necessary to change the model at all points where
the rule is used. In this paper a proposal to separate business from process model and manage it
independently using a business rules engine is done. This involves keeping the business rules in a
repository that controls a business rules engine and a technique to invoke the rule from the model.
This paper is a contribution to improving the design of existing BPMS that would result in highly
flexible business models and modular.
Keywords: Business Ruler, Business Process Engine, Business Process, Business Process
Model, Business Process Management System (BPMS).
1
Ingeniero de Sistemas de la Universidad Autónoma de Colombia. Obtuvo la suficiencia Investigadora y el Diploma de
Estudios Avanzados en el Doctorado de Programación Declarativa e Ingeniería de la Programación y Candidato a Doctor de
la Universidad Politécnica de Valencia UPV (España). Profesor invitado en el Departamento de Sistemas Informáticos de la
UPV. Profesor investigador y docente Tiempo Completo en el Programa de Ingeniería de Sistemas de la Universidad de
Boyacá (Tunja, Boyacá, Colombia). Email: lochaparro@uniboyaca.edu.co. Correo electrónico:
2
Construcción de un proceso de desarrollo de software con base en Model Driven Architecture MDA, Model Driven
Software Development MDSD y BPM. ejecutado en el periodo Marzo de 2010 – Julio de 2013, e inscrito en el grupo de
investigación Grupo de Investigación en Procesos y Calidad de Software - GIPROCAS de la Universidad de Boyacá.
Congreso Andino de Computación, Informática y Educación CACIED 2013

Universidad de Nariño, noviembre 5 a 8 de 2013, Pasto-Nariño-Colombia.
0. Introducción
Un Modelo de Proceso de Negocio (BMP) representa los flujos de actividades de

un proceso de negocio. Para controlar estos flujos, BPMN 2.0 (OMG, 2011)
proporciona un conjunto de elementos de modelado que representan el flujo de
actividades y las reglas que controlan el Proceso (reglas de proceso). Sin
embargo, muchas de las reglas de proceso no son autónomas; sino que, su
actuación depende de una o más reglas de negocio (RN) asociadas interna y
directamente a algunas actividades del modelo de proceso.
La mayoría de los BPMS actuales especifican las reglas de negocio en el modelo

de proceso. Las reglas de negocio, entonces, quedan incrustadas y dispersas por
todo el modelo. Esta situación no es conveniente para la gestión del proceso y
tampoco para la gestión de las RN, pues si una RN cambia, es necesario
modificar el modelo de proceso. Este problema empeora si las reglas varían con
frecuencia y, aún más, si la misma regla está presente en varios elementos del
modelo. Así entonces, para implementar un cambio en una RN, es necesario,
primero, identificar todos los objetos del proceso que contienen esta regla, para
luego hacer la actualización en cada uno de ellos. Además es necesario actuar
con mucho cuidado para asegurar la consistencia entre las actualizaciones a la
misma regla en cada objeto del proceso.
El hecho de tener las RN dispersas en el modelo de proceso viola el principio de

independencia entre el proceso y las RN, enunciado en el ‘manifiesto de las reglas
de negocio’ (BRG, 2003) y conduce a modelos de proceso poco flexibles. Aquí se
propone una estrategia para separar las RN del modelo de proceso, de manera
que se puedan gestionar independientemente con la ayuda de un motor de RN.
Ocurre también que, algunos modelos de proceso son por naturaleza dinámicos;
es decir, requieren cambios en tiempo de ejecución. En estos casos se requiere
que las reglas que orientan tales cambios puedan ser consultadas y/o asociadas
de manera dinámica; es decir, que estas dos acciones se puedan hacer en tiempo
de ejecución.
Nótese que en los casos señalados anteriormente, es conveniente mantener la

independencia entre el modelo de proceso de negocio y las RN. Por un lado
favorece la modularidad y la flexibilidad del modelo de proceso de negocio y de las
reglas de negocio. De otro lado, la asociación y consulta de reglas en tiempo de
ejecución es viable si éstas se han definido y se manejan en forma autónoma.
Por otro lado, la notación de facto para modelar procesos de negocio es el ‘Modelo
y Notación de Procesos de Negocio’ (BPMN). BPMN posee una amplia cantidad
de símbolos que permiten modelar diversos tipos de procesos de negocio; sin
embargo, es casi nula la atención dada a la especificación de RN que influyen en

el flujo del proceso. BPMN 2.0 solo incluye un símbolo de modelado para
especificar RN denominado ‘tarea de regla de negocio’. Este símbolo tiene dos
problemas, está definido para una tarea independiente y sólo solventa el llamado a
reglas de negocio de inferencia, pero no hace referencia a otros tipos de reglas
que pueden tener lugar en el proceso de negocio.
En el capítulo uno se presenta los fundamentos teóricos que sustentan esta

propuesta; en el capítulo dos se describe brevemente la metodología aplicada; en
el capítulo 3 se presenta un enfoque para separar RN del proceso de negocio; en
el capítulo cuatro se presentan las conclusiones; y, finalmente en el numeral 5 se
presentan las referencias bibliográficas.
1. Fundamento Teórico
El propósito principal de un BPMS es apoyar la automatización de los procesos

operacionales de negocio. Para lograr este propósito, es necesario diseñar un
Modelo de Proceso de Negocio (BMP) que exprese el flujo de actividades. Este
flujo está regido por un conjunto de restricciones, muchas de las cuales, a su vez,
dependen de ciertas reglas de negocio definidas por la empresa. En este capítulo
se presentan los principios teóricos que soportan la presente propuesta.
El desarrollo de esta propuesta se basa en la teoría relacionada con los siguientes

temas: Gestión de Procesos de Negocio (BPM) y Sistemas de Gestión de
Procesos de Negocio (BPMS), Gestión de Workflow (WFM) y sistemas de Gestión
de Workflow (WFMS), Modelo y Notación del Proceso de Negocio (BPMN 2.0),
Reglas de negocio (RN).
1.1 BPM, BPMS y Workflow
En el ámbito del tratamiento de procesos de negocio hay tres conceptos que,

aunque diferentes, guardan una estrecha relación. Los conceptos de Gestión de
Procesos de Negocio (BPM), Suite de BPM (BPMS) y Workflow, describen los
fundamentos teóricos, metodológicos y tecnológicos en relación con el manejo de
los procesos de negocio.
1.1.1 Gestión de Procesos de Negocio – BPM
La Gestión de Procesos de Negocio (BPM) es una disciplina que integra un

conjunto de principios, métodos y tecnologías con el propósito de contribuir al
mejoramiento continuo del funcionamiento empresarial. La idea de BPM es hacer
visible el manejo de los procesos de negocio y facilitar los cambios que sean
requeridos (SMITH, 2009)3.
3
La mayor parte del material que se presenta a continuación ha sido extractado de (Howard Smit
and Peter Fingar, Bussiness Process Managent: The Thirt Wave)

Como disciplina, BPM se apoya en un conjunto de principios que surgieron a
finales del siglo pasado, tales como administración total de la calidad (Edwards,
1986), cadena de valor (Porter, 1996), reingeniería de procesos (Hammer, 2000) y
TI como facilitadoras y conductoras de la reingeniería de procesos (Davenport,
1993). En general BPM se percibe como un nivel tecnológico independiente, a
partir del cual es posible automatizar/ejecutar, medir y predecir la evolución de los
procesos de negocio.
1.1.2 Sistemas de Gestión de Procesos de Negocio – BPMS
Un BPMS es un conjunto de herramientas integradas en una suite que apoya la

construcción, ejecución y seguimiento de procesos de negocio. Se caracteriza por
que integra procesos manuales y automáticos a través de diferentes unidades
internas y externas al negocio. Una definición interesante de BPMS es la de
(SMITH, 2009), quien afirma que “un BPMS es un conjunto de herramientas de
software que permiten modelar implementar y gestionar los procesos de negocio,
que abarcan múltiples aplicaciones empresariales, departamentos y ‘partners’”.
Adicionalmente, un BPMS permite definir, modelar, implementar y mejorar los
procesos de negocio, que cumplen con las características técnicas tales que es
posible aplicar el enfoque de BPM. El propósito de un BPMS es extraer los
procesos de las aplicaciones y almacenarlos en un repositorio. De esta manera las
aplicaciones pueden acceder a tal repositorio y trabajar en colaboración con el
BPMS, en lugar de que los procesos estén incrustados en las aplicaciones.
El núcleo de un BPMS es el motor de procesos, mejor conocido como motor de
workflow. La función principal de un motor de workflow es realizar la ejecución
automática de los procesos con base en un BMP ejecutable.
1.1.3 Wokflow y BPMS
BPMS es el resultado de la evolución natural e inmediata de Workflow, como se

muestra a continuación.
En la década de los 70, el reto era procesar de manera eficiente grandes
cantidades de datos, entonces surgió Groupware. En los 80 surgió la necesidad de
grandes cantidades de documentos manuales, así surgió el worflow manual. En
los 90 surgió BMP para superar las limitaciones de workflow.
A partir de 2000 empieza el desarrollo de la tecnología de workflow y su
articulación al enfoque de BPM. Se desarrollaron mecanismos y facilidades para el
intercambio y manejo de información. Posteriormente se desarrollaron
herramientas para hacer seguimiento, análisis y mejora a los procesos. Todas
estas herramientas se empezaron a articular entre si y al workflow para dar lugar a
lo que hoy conocemos como BPMS.

Desde el punto de vista administrativo, workflow se puede percibir como una
composición de reglas de negocio y los mecanismos de flujo que permiten la
automatización y la gestión de los procesos de negocio, con el propósito de lograr
la automatización de tales procesos. En el ámbito de procesos de negocio, el
workflow coordina y controla la comunicación automatizada de trabajo de
computadoras y de personas.
Desde el punto de vista tecnológico, workflow surgió para extraer los procesos
de negocio que están inmersos en el código de las aplicaciones empresariales.
Cuando un proceso está inmerso en el código de las aplicaciones, queda
escondido al usuario y es muy difícil hacer cambios a las tareas de tal proceso.
Por este motivo, se acordó que la mejor solución es separar los procesos de las
aplicaciones y asociarlos a los workflows de la empresa.
En definitiva, el propósito del workflow es apoyar a la empresa en el logro de sus
metas. Es un sistema que automatiza los procesos donde los documentos, la
información y las tareas fluyen entre participantes del sistema, regidos por un
conjunto de reglas preestablecidas.
El núcleo de un BPMS es el motor de proceso (o motor de workflow), cuya función

principal es la ejecución automática de los procesos de negocio. Para realizar esta
función, el motor de workflow toma como base un modelo de proceso de negocio
(o modelo de workflow) prediseñado y genera una instancia de workflow. Esta
instancia es la que realmente se ejecuta.
Un modelo de Workflow es la representación formal de las partes automatizadas

del proceso. Una instancia de workflow es la representación en código
ejecutable de un modelo de workflow. Tal instancia debe satisfacer todas las
restricciones impuestas por el modelo de workflow (Weske, 2012).
Arquitecturas de Gestión de Workflow [Weske]

Si bien BPMS es una evolución de Workflow, es más preciso decir que BPMS es
una extensión de BPMS. Por lo tanto, el estudio de la arquitectura de workflow es
fundamental para entender la arquitectura de BPMS. A continuación se enuncia el
pricncipio fundamental de las arquitecturas de gestión de workflow desde la
perspectiva de Weske (2012).
En el ámbito de workflow tradicional, la separación estricta entre el ‘tiempo de
construcción’ de un modelo de workflow y el ‘tiempo de ejecución’ de las
instancias correspondientes de tal modelo, es un aspecto fundamental.
En el tiempo de construcción, se especifica completamente un modelo de
workflow; es decir, un modelo que una vez creado satisface los requisitos
impuestos por el negocio.

En el tiempo de ejecución, se lleva a cabo el proceso previamente definido por
un modelo de workflow completo. Para este propósito, ocurre lo siguiente:
La separación estricta entre el ‘tiempo de construcción’ y el ‘tiempo de ejecución’
implica que mientras un de proceso (instancia) se ejecuta, no existe ningún vínculo
entre el modelo de workflow y su instancia de workflow. Esta característica implica
que un cambio en el modelo de workflow no afecta su correspondiente instancia.
1.2 Modelo y Notación del Proceso de Negocio (BPMN 2.0)
El Modelo y Notación del Proceso de Negocio (BPMN 2.0) es un estándar del

OMG (2011) para elaborar modelos de proceso de negocio. Es un lenguaje gráfico
que se rige por un conjunto de reglas sintácticas y semánticas. Las reglas
sintácticas definen la forma correcta de combinar los elementos de modelado para
construir diagramas correctos. La semántica define el significado de cada
elemento de modelado y de los diagramas construidos con tales elementos.
El conjunto de ‘buenas prácticas’ propuesto por Silver (2009), constituye un
complemento ideal de las reglas sintácticas y semánticas. La aplicación de tales
prácticas garantiza la legibilidad de los modelos, pues proporciona al modelador
un método jerárquico y las recomendaciones de documentación que garantizan la
legibilidad de los modelos.
BPMN 2.0 busca facilitar el diseño de modelos y ejecución de procesos de
negocios. Los principales objetivos propuestos por OMG para BPMN 2.0 son:
 Proporcionar una notación fácil de entender por todos los usuarios. Es decir,
para los analistas de negocios que crean los modelos iniciales de los procesos,
los técnicos responsables de implementar la tecnología que los ejecutará y las
personas de negocios quienes los gestionan y monitorean.
 Asegurar la visualización orientada a negocio de los lenguajes XML diseñados
para la ejecución de los procesos, tales como WSBPEL4.
 Permitir el intercambio de definiciones de procesos BPMN entre diferentes
herramientas.
BPMN sigue los principios de los diagramas de flujo, pero su principal
característica, es precisamente sus diferencias con estos, según Silver (2009):
 Semántica propia. Define un conjunto de figuras y símbolos estándar con un
significado particular, que no pueden ser modificada y su sintaxis está
respaldada por un conjunto preciso de reglas.
 Describe el comportamiento, de un evento que se activa (dispara).
4
WSBPEL es el acrónimo de Web Service Business Process Execution Language

 Describe el flujo interno y externo. Además de describir el flujo dentro de un
proceso, BPMN, describe las comunicaciones entre los procesos y las
entidades externas como el cliente y los proveedores.
Elementos de BPMN
Uno de los propósitos centrales de BPMN, es proporcionar un mecanismo sencillo
y comprensible para la creación de BMP, con capacidad de manejar la
complejidad inherente a los procesos de negocio. Para alcanzar este propósito
BPMN organizó sus elementos gráficos de la notación en cinco categorías
fundamentales: objetos de flujo, datos, objetos de conexión, carriles de natación y
artefactos.
Los objetos de Flujo son los elementos más importantes de la notación. Estos
objetos pueden ser de tres tipos: eventos, actividades y compuertas. Los datos se
representan mediante objetos de datos, entradas de datos, salidas de datos o
almacenes de datos. Los objetos de conexión permiten conectar los objetos de
flujo entre sí y con otros elementos de información. BPMN proporciona cuatro
objetos de conexión: flujo de secuencia, flujo de mensajes, asociaciones y
asociaciones de datos. Los “carriles de natación” disponen de dos formas de
agrupar elementos de modelado en piscinas y carriles. Los artefactos permiten
adicionar información a los procesos. Los artefactos estándar son: grupos y
anotaciones de texto. Si es necesario, los modeladores o las herramientas de
modelado están en libertad de adicionar tantos artefactos como requieran.
Los elementos básicos de modelado BPMN son: evento, actividad, compuerta,

flujo de secuencia, flujo de mensaje, asociación, piscina, carril, objeto de datos,
mensaje, grupo y anotación de texto. A continuación se hace una breve
descripción de cada uno de estos elementos (tabla NN).
Tabla NN. Elementos básicos de modelado BPMN 2.0

Elemento Descripción Símbolo
Evento Un evento es algo que ocurre durante el
transcurso del proceso (orquestación). Los
eventos afectan el flujo del proceso y
generalmente tienen una causa (disparador) o
un impacto (resultado).
Acepta marcadores para diferenciar diversos
disparadores o resultados.
Hay tres tipos, de acuerdo a como afectan el
flujo: de inicio, intermedio y de finalización.

Actividad Es un término genérico para el trabajo que la
organización realiza en un proceso.
Puede ser atómica o compuesta.
Hay dos tipos de actividad: subproceso y tarea.
Se usan tanto en procesos estándar como en
coreografías
Compuerta Se usa para controlar la divergencia y

convergencia de los Flujos de Secuencia en un
proceso y en una coreografía. Así, se
determinará la ramificación, bifurcación,
combinación y unión de los caminos.
Acepta marcadores para indicar el tipo de
control del comportamiento.
Flujo de Se usa para mostrar el orden en que las

Secuencia Actividades deben ser ejecutadas en un
Proceso y en un Coreografía.
Flujo de Muestra el flujo de mensajes entre dos

Mensaje participantes que están preparados que están
preparados para enviar y recibirlos.
En un diagrama de colaboración, cada
participante se representa en una piscina
separada.
Asociación Se usa para enlazar la información y los
artefactos con elementos gráficos BPMN. Las
anotaciones y otros artefactos se pueden
asociar con elementos gráficos.
Una flecha con cabeza sobre una asociación
indica una dirección de flujo.
(La línea punteada sin cabeza, indica que el
flujo se presenta en ambas direcciones)
Piscina Es una representación gráfica de un
Participante en una Colaboración. Actúa
también como “carril” y un contenedor gráfico
para particionar un conjunto de actividades a
partir de otras piscinas, generablemente en el
contexto de situaciones B2B.
Puede tener detalles internos en la figura de
proceso que se ejecutará.
O puede no tener detalles internos, e. d. puede
ser una “caja negra”.
Carril Es una sub-partición dentro de un proceso,
algunas veces dentro de una piscina, y se
extenderá a lo largo del proceso.
Se usan para organizar y categorizar las

actividades.
Objeto de Proveen información a cerca de qué
datos actividades requieren ser ejecutadas y lo que
producen.
Pueden representar un objeto singular o una
colección de objetos.
Los datos de entrada y de salida proveen la
misma información para el proceso.
Mensaje Un mensaje se usa para representar los

contenidos de una comunicación entre dos
Participantes.
Grupo (una Un grupo es una agrupación de elementos

caja alrededor gráficos que están dentro de la misma
de un grupo categoría. Este tipo de agrupación no afecta el
de objetos flujo de secuencia dentro del grupo.
dentro de la El nombre de categoría aparase en el diagrama
misma como como una etiqueta del grupo.
categoría)
Las categorías se pueden usar para propósitos
de análisis o documentación. Los Grupos son
una forma en que las categorías de objetos se
pueden visualizar en el diagrama.
Anotación de Son mecanismos para que un modelador
texto (que se proporcione información textual adicional para
adjunta con enriquecer el diagrama BPMN.
una
asociación)
Fuente (OMG, 2011)
1.3 Reglas de Negocio

Las reglas de negocio (RN) han sido definidas principalmente desde las
perspectivas del negocio y del desarrollo de software.
Desde la perspectiva del negocio, se considera que las RN son elementos que
regulan la estructura y comportamiento del negocio. SBVR5 dice que una regla de
negocios es una “regla que está bajo la jurisdicción del negocio”; donde “la
jurisdicción del negocio” es la comunidad semántica (personas) que pueden
expedir, revisar y suprimir las RN que la gobiernan y orientan, cuando lo considere
conveniente [OMG2008].
Desde la perspectiva de TI, las RN son requisitos primordiales del software

empresarial; es decir, son “declaraciones de políticas o condiciones que se deben
5
SBVR es el acrónimo de “Semantics of Business Vocabulary and Business Rules”

cumplir” en el sistema y también son “…estipulaciones de procedimientos que
deben ser satisfechas” [Martin1995] y [Odell1995].
Las bases para la formalización de las RN las proporciona el artículo seminal

[BRG2000]6. Propone los siguientes principios fundamentales: el vocabulario del
negocio está conformado por definiciones de términos, los hechos relacionan
términos entre sí para describir la estructura operativa del negocio, las
restricciones (aseveraciones de acción) expresan limitaciones sobre el
comportamiento del negocio y las derivaciones definen la forma de obtener nuevos
conocimientos a partir de información ya conocida.
Taxonomía de las RN
Las RN han sido objeto de diversas propuestas de clasificación [BRG2007]

[BRG2010] [OMG2008] [OMG-BMM] [Ross2010] […]. Algunas propuestas reflejan
la perspectiva del negocio, otras la perspectiva de TI y otras mezclan las dos
perspectivas.
En el trabajo de Chaparro (2012), se propone una clasificación basada en el SBVR

desde una perspectiva conceptual, que aporta elementos importante a los
objetivos de este trabajo. Esta clasificación considera tres tipos de RN básicos:
Reglas estructurales, Reglas operativas y reglas de derivación. Cada una de ellas,
a su vez, se divide en subtipos como se muestra en la figura 1.
Para este estudio, son de interés las reglas operativas y las reglas de derivación,
ya que estos dos tipos de reglas pueden influir el flujo de las actividades de un
proceso de negocio. Las reglas estructurales, prioritariamente describen las
relaciones existentes entre los objetos de un sistema de información, por lo que no
son de interés para este trabajo.
Las reglas operativas expresan restricciones que influyen en el resultado de

ejecución de las acciones. Describen posibilidades del tipo debe (o, ‘debiera’), no
debe (o ‘no debiera’). En este nivel las reglas operativas pueden ser reglas de
estímulo respuesta o reglas de restricción de operación. Las reglas operativas se
pueden representar como especificaciones de pre y post condiciones.
Una regla de estímulo respuesta establece que una acción se debe ejecutar
(automáticamente) cuando se cumple una determinada condición (reglas CA).
Otras reglas reaccionan cuando ocurre un evento y se cumple una condición
(ECA), otras simplemente reaccionan cuando ocurre un evento, sin que medie una
condición adicional (EA). En este caso la ejecución automática de la acción ocurre
como respuesta a un evento y/o a que se cumple una determinada condición.
6
Todo el apartado ha sido tomado de esta fuente

Una restricción de operación describe las condiciones, anteriores y/o posteriores,
necesarias para asegurar que la ejecución de una acción es correcta. Estas
restricciones son independientes del evento que activa la operación.
- R. de Herencia
- R. de asociación
- Relación entre objetos - R. agregación
R. Estructural - R. de Role
(Relación entre
Objetos) - R. de población
- Restr. Integridad de estado - R. de cardinalidad
- R. valor de atributo
- Otras restricciones
Reglas de
- R. de condición previa
Negocio - Restricción de operación
- R. de condición posterior
R. Operativa
- ECA
(Restricción de - R. de Estímulo respuesta - CA
acción) - EA
- R. privilegios de agente
- Inferencia
R. de derivación
- Cálculo matemático
Figura 1. Clasificación conceptual de las reglas de negocio (Fuente: el autor)
Una regla de derivación genera un hecho derivado a partir de una regla de

inferencia o una fórmula de cálculo matemático.
Un regla de inferencia produce un hecho derivado como conclusión de inducción

lógica (desde lo particular) o deducción lógica (a partir de principios generales).
Para esto se vale de hechos previamente conocidos.
Una regla de cálculo produce un hecho (resultado) derivado mediante la ejecución

de un algoritmo o fórmula matemática. Para este propósito utiliza uno o más datos
conocidos y operaciones matemáticas.
2. Metodología
Para realizar la propuesta que se describe en este artículo, se utilizó investigación

descriptiva I+D. Para determinar el conocimiento actual en relación con BPMS,

motores de workflow, BPMN y reglas de Negocio, se aplicó técnicas de
recolección y estudio de documentos. Con este procedimiento se determinó el
estado general del conocimiento en relación con estos temas y se estableció el
problema de estudio.
Se estudió el funcionamiento de varios BPMS, entre ellos Aura Portal y un Motor

académico de la UNAL. Se estudió la documentación de los anteriores BPMS y
además, la documentación de Intalio, SAP e IBM. De esta manera se determinó el
problema bosquejado: las RN se incluyen dentro del modelo de proceso o no está
claro donde ubicarlas y gestionarlas.
Para realizar la propuesta, se profundizó en BPMN 2.0, Reglas de Negocio y

BPMS (arquitecturas de workflow). Así se determinó que una RN puede afectar
más de un elemento del modelo de proceso y que en una actividad pueden actuar
más una regla.
La investigación I+D se aplicó al desarrollo de un prototipo de motor de RN que

procesa reglas de inferencia. Este prototipo se utilizará en etapas más avanzados
de la investigación, para probar algunas hipótesis, respecto el manejo de reglas
de inferencia.
3. Enfoque para Separar las RN del Proceso de Negocio
3.1 Análisis del Estado Actual
Aquí se hace una propuesta para extraer las RN del modelo de proceso de
negocio, de manera que su almacenamiento y gestión se haga desde un motor de
RN. Este enfoque conduce a procesos de negocio más flexibles y modulares. Los
siguientes son los principales aspectos analizados en los modelos de proceso
actuales y en la notación de BPMN:
 Existen dos tipos de reglas en un proceso de negocio: las reglas de proceso
(RP) y las RN. Las RP determinan el flujo de las actividades de proceso; ellas
se representan principalmente mediante compuertas divergentes y
convergentes en BPMN. Las RN influyen sobre las RP influyen de acuerdo con
el tipo de RN.
 Los principales tipos de RN que pueden influir sobre las RP son: reglas de
restricción (precondición / post-condición), reglas de estímulo respuesta
(generadas por eventos: ECA, EA y CA), reglas de inferencia y reglas de
cálculo.
 BPMN 2.0 solo proporciona una símbolo para representar el modelado de RN;
la tarea de regla para representar el llamado a reglas de inferencia.
 Como existen varios tipos de RN, ocurrirá lo siguiente:
o Debe definirse un repositorio para almacenar cada tipo de RN.

o Para cada tipo de RN se debe definir un símbolo diferente en BPMN.
Estos símbolos se incrustarán en un elemento de modelado (actividad
y/o compuerta).
o En el elemento del proceso se colocará la referencia de la regla y los
atributos de llamado y en un motor de reglas se especificará y se
gestionará todas las RN.
 Un motor de RN es el responsable por el almacenamiento, gestión y validación
de las RN. Después de una invocación de un RN, el MRN procesa y/o valida la
RN y devuelve una respuesta.
 El manejo de las RN en modelos de proceso flexibles requiere mayor cuidado,
pues es posible que se requiera implementar la asignación y descubrimiento de
la RN en tiempo de ejecución.
3.1 Separación de RN de Procesos Estables
Aquí se considera que un proceso estable es aquel cuyo flujo de actividades varía
muy poco y con una frecuencia muy baja. Sin embargo, independientemente del
tipo de proceso, muchas de las reglas de proceso dependen de procesamiento
previo de una o más reglas de negocio. Además, como las RN pueden tener una
alta tendencia al cambio (volatilidad) y una misma regla puede actuar en diversos
puntos del proceso, es preciso que las reglas de negocio sean extraídas del
proceso para ser gestionadas de manera independiente del proceso.
Sea el caso de una orden de compra que una vez recibida, deberá enviar la orden
al jefe de despachos si se trata de un cliente corriente o a un directivo para que
autorice un descuento si se trata de un cliente especial. Hasta aquí, pareciera que
la aplicación de la RP es suficiente para continuar con el flujo de proceso, pero en
realidad su aplicación depende de RN de inferencia que deben ser procesadas
previamente para saber si el cliente es corriente o especial.
Nótese que las RN que permiten inferir el tipo de cliente, pueden cambiar por
políticas de la empresa. Si las reglas se procesan independientes del proceso, no
será necesario hacer cambios en cada uno de los puntos del proceso que tal regla
afecta, solo bastará con hacer cambios en el repositorio donde esté almacenada la
regla. Además, no habrá problemas de consistencia, pues la regla solo se modifica
una vez.
En la figura 2 se muestra la estrategia general para separar las RN del proceso

principal. Nótese que una regla puede afectar varios elementos del proceso y un
elemento del proceso puede ser afectado por varias RN.
Mediante la estrategia mostrada en la figura N1, el motor de proceso de BPMS se

encarga de controlar la ejecución del proceso de negocio y un motor de reglas de

negocio asume la gestión y procesamiento de las RN. Así, cuando un elemento
del proceso requiere hacer uso de una RN, solo la invoca y el motor de reglas se
encarga de procesar la petición y devolver un resultado. En motor de procesos,
recibe el resultado y conforma una RP para continuar la ejecución del proceso.
A1
A2
X R1
R2
R3
R4
A3 A4
R5
An
Figura 2. Reglas de negocio separadas del proceso (Fuente: el autor)
De otro lado, si una RN requiere cambios, estos se hacen con el apoyo del motor
de reglas, y el modelo de proceso se mantiene intacto.

3.2 Influencia de las RN sobre los Elementos del Proceso
Una RN puede afectar diversos tipos de elementos del proceso; es decir, puede
influir sobre una actividad, sobre una compuerta, sobre un evento o sobre una
combinación de estos elementos. El problema radica en cómo identificar esta
influencia.
Se ha dicho que los tipos de reglas que pueden afectar el proceso son restricción
de operación (precondición y postcondición), reglas de estímulo respuesta (EA,
ECA) y reglas de derivación (calculo e inferencia).
Regla Evento Condición Acción

Una RN de negocio de este tipo puede estará asociada a una RP representada
por una compuerta OR inclusiva. La RN tendría que estar asociada a un evento
(por ejemplo, un evento de mensaje).
En la figura 3 el evento de inicio del proceso es un mensaje de oferta para un

cliente. La regla de proceso está representada por una compuerta Or inclusiva que
tiene tres caminos de salida. Esta RP toma el resultado de la evaluación de por lo
menos tres RN:
 R1: Si el cliente es local va a lectura por parte del jefe III
 R2: Si el importe mayor que 500 va a lectura por parte del jefe II
 R3: Si el importe menor o igual 500 va a lectura por parte del jefe I
La R1 indica la acción a realizar independientemente del monto de la oferta. Las

R2 y R3 dependen del monto y leen las ofertas sea le cliente local o no. Las
Reglas R2 y R3 pueden cambiar, por ejemplo los montos. Así que, de acuerdo con
esta estrategia tal modificación se hace con ayuda del motor de reglas pero el
modelo se mantiene inmodificable.
Regla de derivación
Una regla de derivación puede ser de cálculo matemático o de inferencia. La
primera se define mediante un algoritmo o fórmula matemática que puede incluir
variables y valores constantes. Una regla de inferencia por lo general actúa junto
con otras reglas que una vez combinadas apropiadamente permite obtener u
resultado.
Un conjunto de reglas de inferencia está asociado con RP, por lo general mediante
una actividad que fluye hacia una compuerta Or exclusiva. Al combinar las RN de
inferencia arrojan un resultado sobre los que la RP actúa para conducir al flujo por
uno y solo un camino.

El comercial introduce
Datos de la oferta
Importe Oferta y/o

Localidad cliente?
Importe hasta 500 Oferta Local
Importe mayor que 500
Leer oferta Leer Oferta Leer Oferta
Jefe I Jefe II Jefe IIi
Ajustar Oferta y
Enviar al cliente
Comercial
Espera de fax y/o

espera una semana
Espera que
Espera mensaje pase 1
de confirmación Semana y no
por Fax llega Fax
Confirmar el
estado de oferta
Comercial
Oferta aceptada?
No
si
Esperara hasta
las 13 h.
Envío de pedido
Dpto. de envios
Se activa cuando
pasan 24 horas
Comentarios
Jefe Dpto Envíos
Figura 3. Proceso detallado de una oferta para un cliente (Fuente: el autor)

En la figura 4, una actividad automática ‘analiza las condiciones del cliente’ e
infiere el tipo cliente que realiza la orden de pedido. Esta actividad invoca un
conjunto de RN para que mediante el procesamiento del motor de RN realice la
inferencia correspondiente. De esta manera que la RP pueda recibe el resultado
para conducir el flujo pertinente. Algunas de las RN necesarias para hacer esta
inferencia pueden ser las siguientes:
 R1: Un cliente es normal si el total de compras del año anterior es menor a 100
 R2: Un cliente es normal si ha colocado como máximo tres órdenes en el año
anterior
 R3: Un cliente es oro si el total de compras del año anteriores mayor o igual a
100 y menor que 700
 R4: Un cliente es oro si ha colocado más de tres órdenes el año anterior y el
total de compras es mayor que 550.
 Un cliente es platino si el total de compras del año anterior es mayor que 700.
Las anteriores reglas pueden cambiar sus rangos de valores o inclusive, se

pueden agregar o quitar algunas reglas. Pero el conjunto de reglas
predeterminado, permite establecer el tipo del cliente que ha colocado la orden de
pedido. Al actualizar tal conjunto de reglas el modelo se mantiene igual.
Un conjunto de reglas de cálculo está asociado con una RP, por lo general
mediante una actividad que fluye hacia una compuerta Or exclusiva. Al aplicar la
regla de cálculo se obtiene un resultado sobre los que la RP actúa para conducir al
flujo por uno de los caminos.
En la figura 4, una actividad automática calcula el total de la orden de pedido.

Esta actividad invoca una RN del motor de reglas, el cual calcula el total y
devuelve el resultado. Con este resultado la RP correspondiente conduce el flujo
por el camino correspondiente. La RN que permite hacer este cálculo es:
 R1: El total de la orden total de la orden más IVA menos descuento aplicable.
Regla de Restricción de Operación

Las reglas de restricción de operación se representan como precondiciones y/o
post-condiciones asociadas a una tarea. Una precondición describe una condición
que se debe cumplir antes de la ejecución de una actividad. Una post-condición
señala un estado que se debe cumplir después que la actividad se ha realizado.
Las dos condiciones se deben cumplir para que la ejecución sea satisfactoria.
En la figura 3 se deben cumplir uno de dos eventos (Evento Acción) para poder
continuar con la actividad de ‘confirmar el estado de la oferta’. Esta configuración
representa la RP que controla este flujo. En la compuerta paralela (rombo con un
+) se debe asociar las reglas:
 R1: Se debe esperar una confirmación vía Fax indicando la aceptación o
rechazo de la oferta.

 R2: Si pasa una semana y no se ha recibido Fax de confirmación, se asume
que la oferta ha sido rechazada.
 R3: el estado de la oferta debe ser ‘aprobada’ o ‘rechazada’ por el cliente,
nunca ‘sin información’
El sistema recibe orden

de pedido
Analizar condiciones
del cliente
Tipo de cliente?
Cliente Premium Cliente Normal

Cliente Oro
Aplicar condiciones Aplicar condiciones Aplicar condiciones

Premium Oro Normal
comercial I Comercial II Comecial III
Calcular total
contable
Total mayor o igual que 100 Total menor que 100
Facturar régimen Facturar régimen

común simple
comercial I Comecial III
Empacar y enviar
Despachador
Figura 4. Proceso de una orden de pedido (Fuente: el autor)
La regla de proceso, en este caso está conformada por una compuerta paralela de
entrada y una compuerta exclusiva de salida, que controlan dos eventos. Esta
configuración indica que solo es necesario esperar que ocurra uno de los dos
eventos para continuar el flujo del proceso.

La reglas R1 y R2 deben estar asociada a la compuerta paralela anteriores a los
eventos que indica con la compuerta de salida que uno de los eventos es
suficiente para continuar el flujo a la actividad ‘confirmar estado de oferta’. La regla
R3 debe estar asociada a la actividad ‘confirmar estado de oferta’; entonces tal
estado debe ser ‘aprobada’ o ‘rechazada’.
Al igual que en los casos anteriores, las reglas pueden ser actualizadas sin que el
proceso tenga que cambiar. Por ejemplo, puede cambiar el tiempo de espera para
la llegada del fax o el tipo de documento aceptado.
3.2 Discusión de resultados
En este artículo, se presentó una propuesta para separar las RN de los modelos
de proceso con el propósito mejorar la flexibilidad y modularidad de los procesos
de negocio automatizados. La estrategia básica gira en torno a identificar las RN
que se encuentran escondidas en el proceso de negocio para hacer explicita su
relación con las RP. En este caso, se incursionó un poco más, pues descubrió
algunas relaciones entre tipos de RN y patrones de modelo de proceso. Este
hecho favorece la sistematización del proceso de separación de la RN y la
estrategia de invocación.
La propuesta de separación se hizo en el marco de la notación BPMN 2.0, que es

el estándar de facto avalado y promovido por la OMG. De esta forma, se le
proporciona un piso firme a la propuesta, considerando el prestigio mundial de
esta organización entre los fabricantes de BPMS y de la comunidad investigadora
internacional.
La clasificación de RN asumida para esta propuesta, está avalada en un amplio

estudio anterior del autor (Chaparro, 2012) y basado en principalmente OMMG,
SBVR y BRC.
Para realizar esta propuesta se aplicó técnicas documentales de recolección y

estudio de artículos, memorias, libros de texto y estándares. De esta manera se
estableció el estado del conocimiento al relacionado con el problema de estudio.
Se obtuvo documentación actualizada y clásica provenientes fuentes de la más
alta calidad, entre ellas, investigaciones actuales publicadas por Springer Verlag,
OMG e IEEE.
Por otro lado se estudió las principales características de BPMS como Aura Portal.
Se estudiaron algunos casos de modelos de procesos para determinar la relación
entre las reglas de proceso y las reglas de negocio, para así determinar cómo
hacer su separación. Los modelos presentados en este estudio, fueron
desarrollados con Microsoft Visio utilizando la notación de BPMN.

4. Conclusiones
Las principales conclusiones derivadas de la propuesta que se presenta en este

artículo son las siguientes:
 Con esta propuesta se mostró que la gestión de la reglas de negocio de
manera independiente del proceso de negocio (automatizado) favorece la
flexibilidad del proceso de negocio. Las modificaciones de las RN ya no están
atadas a modificaciones en el proceso de negocio.
 Diferenciar entre Regla de Proceso y Regla de negoció constituye un asunto
fundamental, pues proporcionó el hilo conductor para identificar los tipos de
RN que poseen nexos con los patrones estructurales de modelado que
representan las RP.
 Se dieron argumentos sólidos que defienden las ventajas de separar las RN
de del proceso de negocio. Por ejemplo, si una misma RN aplica en diferentes
puntos de uno o más procesos, solo hay que modificarla un vez haciendo uso
del motor que la gestiona.
 La cantidad de símbolos y patrones estructurales de BPMN 2.0 que pueden
estar relacionados con los tipos de RN identificados, son muchos más de los
que se relacionaron en esta propuesta, así que queda un trabajo amplio por
realizar.
 Otro aspecto que queda pendiente es la creación de un marco que conduzca a
implementar la invocación de RN desde el motor de procesos y el
procesamiento y respuesta des un motor de reglas.
5. Referencias bibliográficas
BRG - Business Rules Group (2000). Business Rules Grop – BRG. Defining Business Rules – What
are Really? Final Report, Revision 1.3 July, 2000.
BRG - Business Rules Group (2007). The Business Rules Group BRG. The Business Rules
Motivation Model – Business Governace in a volatile World. Copyright, 2007.
BRG - Business Rules Group (2009). The Business Rules Manifesto. Version 2.0 (2003)
http://www.businessrulesgroup.org/brmanifesto.htm#top. Copyright 2003-2013 BRG.
CHAPARRO, Luis (20012). Clasificación de las Reglas de Negocio Orientada por MDA que Apoya el
Desarrollo de Software Empresarial. EIISI 2012.
DEVENPORT, Thomas. Process Innovation: Reengieering wortk trhough Information Technology,
Harvard Business Press, ISBN 0875843662 1993.
EDWARDS, William (1986). Out of the Crisis. MIT Press. ISBN 0-911379-01-0. OCLC 13126265.
HAMMER, Michael & CHAMPY, James. Reengeneering the corporation: A Manifesto for Business
Revolution, summaries.com, 2000
http://moodle.unitec.ac.nz/pluginfile.php/192283/mod_resource/content/0/Reengineering_The_
Corporation.pdf.
MARTIN, James, ODELL, James (1998). Object Oriented Methods, Prentice Hall, New York 1998.
ODELL, James (1998). Odell, James. “Business Rules”, Object Magazine, Jan 1995, pp. 53-56.

OMG – BMM Object Management Group OMG (2008). Object Management Group OMG. Business
Motivation Model Available Specification. OMG Document Number: formal/2008-01-02.
OMG – Object Management Group OMG (2008). Semantics of Business Vocabulary and Business
Rules (SVR) v1.0. OMG Available Specification. OMG Document Number: formal/2008-01-02 .
http://www.omg.org/spec/SBVR/1.0/PDF.
OMG – Object Management Group (2011). Business Process Model and Notation (BPMN). OMG
Documment Number: formal/2011/01-03, version 2.0 http://www.omg.org/spec/BPMN/2.0.
PORETER, Michael (1996). What is strategy? Harvard Business Review, November–December, 61-
78. The value chain.
ROSS, Ronald (2010). "What Is a Business Rule?" Business Rules Journal, Vol. 11, No. 3
(Mar. 2010), URL: http://www.BRCommunity.com/a2010/b525.html.
SILVER, Bruce (2009). BPMN Method and Style: A Lavels-based Methodology for Business Process
modeling and improvement Using BPMN 2.0. Cody-Cassidy 2009. ISBN-13: 9780982368107.
SMITH, Howard & FIGER, Peter (2009). Business Process Management: the Third Wave. Fourth
Anniversary Edition. Meghan-Kiffer, 2009.
WESKE, Mathias (2012). Business Process Management: Concept languages and architectures.
Springer 2012.

Información del Proyecto
Título del
*
documento Enfoque para Flexibilizar el Modelo de Proceso de Negocio
Título del proyecto*
Construcción de un Producción de software con basen e MDA y MDSD
Investigador(es)*
Luis Oliverio Chaparro Lemus y Federico Gómez Estupiñan
Coinvestigador(es)
Estudiantes del Semilero TECNOSOFT
Grupo de GIPROCAS: Grupo de Investigación en Procesos y Calidad de Software

investigación*
Dependencia* Universidad de Boyacá. Facultad de Ciencia e Ingeniería. Programa de
(Universidad, Facultad, ingeniería de Sistemas
Departamento)
Objetivo del Construir un Proceso de Desarrollo de Software con base en los
proyecto* estándares establecidos por Model Driven Architecture MDA y los
principios promovidos por Model Driven Software Development MDSD.
Resumen (50 a 100 Como lo especifica el título, el objetivo de este trabajo fue construir un
palabras)* proceso con base en el marco de la Arquitectura Dirigida por Modelos
MDA y en los principios del Desarrollo de Software Dirigido por Modelos
MDSD. Para lograr el objetivo planteado se estudio la teoría a cerca de
MDA y MDSD; se asociaron modelos y artefactos a cada nivel MDA (CIM,
PIM y PSM) y se establecieron las correspondencias entre los modelos
MDA adyacentes. Para ilustrar el proceso y la conformación de los niveles
MDA, se tomó un caso de uso de conocimiento común, el RentaCar, el
que se modificó y se amplió para este caso. El proceso resultante incluye
un marco detallado que describe el flujo de trabajo, la asociación de
diagramas y artefactos a cada nivel y la caracterización de cada
diagrama. Este proceso se perfila como un realización concreta de la
propuesta de MDA y MDSD.
Tipo de proyecto* Investigación: _X_ Innovación: __

Desarrollo: __ Extensión: __
Otro: __ ¿Cuál?:
Fecha inicio* 02.2009
Fecha finalización* 07.2013
Duración _44_ meses
Metodología*
(resumen de las fases Por sus características, este proyecto implicó diversos tipos de
procedimentales actividades, tales como: recopilación y análisis de información teórica
planteadas o referente a MDA y MDSD, identificación de herramientas de
realizadas) transformación y análisis de su funcionamiento, identificación de las
taxonomías de transformaciones de modelos y estudio de cada tipo,
diseño del marco del proceso y diseño de las transformaciones entre
modelos y prueba del proceso resultante.
*
Datos indispensables

Como se puede apreciar el proyecto abarcó diversos tipos de actividades
globales que se abordaron mediante un tipo de investigación diferente
así:
Investigación Exploratoria. Mediante éste tipo de investigación, se

identificaron los principios fundamentales de MDA, MDSD, XMI y UML2.
Se recopiló información relevante de cada uno de los temas para
conformar un texto general explicativo, mapas conceptuales y cuadros
que permitieron entender cada tema y su relación con los demás temas.
Investigación Descriptiva. Con base en la investigación exploratoria, se

hizo una caracterización de MDA, MDSD, XMI y UML. Para cada uno de
los temas se describieron sus características relevantes vistas desde la
perspectiva de los autores más destacados, además de las guías que
proporciona el OMG. Las descripciones están acompañadas de
elementos gráficos que ayudan a expresar mejor cada tema. También se
usó este tipo de investigación para describir el proceso que se construyó,
así como los modelos y transformaciones de modelo necesarias.
Caso de Estudio. Se diseñó un caso de estudio para comprobar las

hipótesis de trabajo. Adicionalmente, se hicieron pruebas a técnicas y
métodos que se utilizaron para conformar proceso de desarrollo de
software.
Investigación y Desarrollo I+D. Mediante I+D se construirá el proceso de

desarrollo de software; esto implica su marco general, etapas, modelos, y
especificación de correspondencias entre modelos.
Adicionalmente a los métodos propios de los tipos de investigación antes

mencionados, se utilizaron el Lenguaje de Léxico Extendido LEL, El
Léxico Orientado a Modelado LOM y las Reglas de Negocios.
Resultados En este trabajo se ha diseñado un proceso de desarrollo de software

obtenidos* basado en MDA y MDSD. El núcleo del proceso está conformado por los
modelos globales (niveles) de MDA, es decir CIM, PIM, PSM. Con base
en estos modelos se diseñó un marco de proceso, se determinaron los
modelos específicos y los artefactos que deben conformar cada nivel
MDA. De esta manera se elaboró una aproximación inicial que requiere
ser profundizada en sus diversos aspectos.
La investigación proporciona un aporte importante a la automatización

del proceso de software, ya que logró conformar un proceso basado en
MDA y MDSD orientado a definir las bases para automatizar el proceso.
Para lograr este propósito fue necesario asignar un conjunto de modelos
particulares a cada modelo global de MDA, establecer el papel de cada
modelo particular e identificar su relación con los otros modelos del
mismo nivel. Esta estrategia permite establecer correspondencias top-
down desde el CIM hasta el PSM, de manera que se facilita la definición
de trasformaciones verticales que apoyan la automatización del proceso
de software.
El proyecto de investigación partió de la suposición de que para definir un

proceso que automatice el desarrollo de software, además de asumir el
modelo como su eje fundamental, es necesario definir los modelos,
diagramas y procedimientos que debe conformar cada nivel global de
MDA. Este es el objetivo que se planteó para este trabajo, y que se
desarrolló a largo del mismo. También se hizo una aproximación concreta
para contribuir con el propósito de MDA de automatizar el proceso de
software, que se constituye en un aporte significativo al conocimiento,
dado que no se tiene información de que otros procesos basados en
MDA aborden el problema con el detalle asumido en la presente
investigación.
Observaciones Como cada nivel de MDA ha sido dotado con un conjunto de modelos y/o
artefactos que permiten su amplia caracterización y se han definido las
correspondencias entre los elementos de modelado que generan cada
nivel, queda por hacer un amplio número de trabajos, entre ellos, los
siguientes:
 Concreción del proceso específico dentro de cada nivel MDA. Esto
es, cómo al interior de cada nivel algunos modelos están relacionados
con otros y cómo cada modelo influye en la generación de otros.
 Definición detallada de las correspondencias verticales entre modelos
de diferente nivel de abstracción, y las correspondencias horizontales
entre modelos del mismo nivel.
 Diseño específico de las transformaciones entre elementos de
modelado, para generar otros modelos.
 Identificación de patrones y reglas para conseguir que las
transformaciones sean sistemáticas, de manera que se asegure que
el proceso llegue a ser plenamente repetible y consistente.
Definir correspondencias y transformaciones PIM con PSMs concretos,

para generar código en entornos Java o .NET.
* Información indispensable

Información de los autores7
Ítem Detalles
Nombres: Luis Oliverio
Apellidos: Chaparro Lemus
Insertar
Nacionalidad: Colombiano
Fotografía
Fecha de nacimiento: Junio 28 de 1957
reciente
Lugar de nacimiento: Tota Boyacá
Documento de identificación: 19289972
Título: Ingeniero de Sistemas
Institución: Universidad Autónoma de Colombia
Año obtención: 1990
Título:
Información
Institución:
académica
Año de obtención:
Título:
Institución:
Año de obtención:
Dirección: Carrera 10 No 74B-28
Ciudad: Tunja
Información País: Colombia
residencial Teléfono fijo: 7451213
Teléfono móvil: 3123771943
Correo personal: lochaparro@uniboyaca.edu.co
Cargo: Docente investigador
Institución: Universidad de Boyaca
Dirección: Carrera 2 Este No. 64-169
Información Ciudad: Tunja
laboral actual País: Colombia
Teléfono fijo: 7450000 ext. 6207
Teléfono móvil:
Correo laboral: lochaparro@uniboyaca.edu.co
Correo personal __ Correo laboral _X_
Contacto Correspondencia a residencia __ Correspondencia a oficina __
preferido Teléfono fijo residencia __ Teléfono fijo oficina __
(señalar con x) Teléfono móvil personal __ Teléfono móvil laboral __
Autor. (Año). Título del artículo. En: Título de la revista. Número del volumen,
número de la entrega (mes). Lugar de publicación: Editorial. Paginación. ISSN.
Luis Oliverio Chaparro Lemus y Carmen Constanza Uribe Sandoval. (2011).

Métodos Formales para la Especificación de Requisitos Tempranos. En: Revista
Artículos
Proyección Universitaria. Número 36, Septiembre-Diciembre. Universidad de
publicados en
Boyacá.. Páginas 49 a 72. ISSN 0120-5951.
los últimos
dos años
Luis Oliverio Chaparro Lemus y Juan Federico Gómez Estupiñan. (2012). Una
Visión del Desarrollo de Software Utilizando Modelos. En: Revista Gerencia
Tecnológica Informática GTI. Volumen 11, Número 29, Enero-Abril.
Bucaramanga: Universidad Industrial de Santander UIS. Páginas 69 a 82. ISSN
1657-8236.
7
Para trabajos colectivos se solicita que se multiplique la tabla formato, y se organice de acuerdo a
la ubicación de cada autor en el encabezado del documento.

Ítem Detalles
Luis Oliverio Chaparro Lemus y Juan Federico Gómez Estupiñan. (2012). MDA
y MDSD: El Papel de los Modelos en el Desarrollo de Software. En: Revista
Proyección Universitaria. Número 37, Enero-Junio. Tunja: Universidad de
Boyacá. Páginas 70 a 90. ISSN 0120-5951.
Luis Oliverio Chaparro Lemus (2011). Ponencia: “Reglas de Negocio: un
Enfoque que Mejora el Desempeño de los Sistemas de Información” En:
Segundo Seminario Internacional de Gestión Tecnológica en Ingeniería,
Tecnologías de la Información y las Comunicaciones, Industria y Medio
Ambiente. 29 y 30 de Septiembre de 2011. Tunja: Universidad de Boyacá.
Luis Oliverio Chaparro Lemus (2011). Ponencia: -“Reglas de Negocio: un

Nuevo Enfoque de Sistemas Informáticos para la Gestión Dinámica
Empresarial”. En: II Encuentro Internacional y VI Nacional de Investigación en
Ingeniería de Sistemas e Informática EIISI 2011. 5, 6 y 7 de Octubre de 2011.
Tunja: Universidad Pedagógica y Tecnológica de Colombia UPTC.
Participación
Investigación en Ingeniería de Sistemas e Informática – EIISI 2011. Páginas 31
en eventos
a 40. ISSN 2248-7948.
académicos
en los últimos
Luis Oliverio Chaparro Lemus (2011). Conferencia: Bases de Datos Activas. En:
dos años
Seminario de Actualización en Teleinformática. Noviembre 29 y 30 de 2011.
Paipa: Servicio Nacional de Aprendizaje SENA Regional Boyacá.
Luis Oliverio Chaparro Lemus (2012). Ponencia: “Una Clasificación de las

Reglas de Negocio Compatible con la Arquitectura Dirigida por modelos MDA”.
En: III Encuentro Internacional y VII Nacional de Investigación en Ingeniería de
Sistemas e Informática EIISI 2012. 3, 4 y 5 de Octubre de 2012. Sogamoso:
Universidad Pedagógica y Tecnológica de Colombia UPTC, Escuela de
Ingeniería de Sistemas. Investigación en Ingeniería de Sistemas e Informática –
EIISI 2012.


Articulo Congreso Andino LOC PDF

Cargado por

Copyright:

Formatos disponibles

Articulo Congreso Andino LOC PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Articulo Congreso Andino LOC PDF

Cargado por

Copyright:

Formatos disponibles

Enfoque para Flexibilizar el Modelo de Proceso de Negocio

[More flexible approach to Business Process Model]

Eje temático: Ingeniería de Software Temática: Automatización de Procesos

Congreso Andino de Computación, Informática y Educación CACIED 2013

Un Modelo de Proceso de Negocio (BMP) representa los flujos de actividades de

La mayoría de los BPMS actuales especifican las reglas de negocio en el modelo

El hecho de tener las RN dispersas en el modelo de proceso viola el principio de

Nótese que en los casos señalados anteriormente, es conveniente mantener la

Congreso Andino de Computación, Informática y Educación CACIED 2013

En el capítulo uno se presenta los fundamentos teóricos que sustentan esta

El propósito principal de un BPMS es apoyar la automatización de los procesos

El desarrollo de esta propuesta se basa en la teoría relacionada con los siguientes

1.1 BPM, BPMS y Workflow

En el ámbito del tratamiento de procesos de negocio hay tres conceptos que,

1.1.1 Gestión de Procesos de Negocio – BPM

La Gestión de Procesos de Negocio (BPM) es una disciplina que integra un

Congreso Andino de Computación, Informática y Educación CACIED 2013

1.1.2 Sistemas de Gestión de Procesos de Negocio – BPMS

Un BPMS es un conjunto de herramientas integradas en una suite que apoya la

1.1.3 Wokflow y BPMS

BPMS es el resultado de la evolución natural e inmediata de Workflow, como se

Congreso Andino de Computación, Informática y Educación CACIED 2013

El núcleo de un BPMS es el motor de proceso (o motor de workflow), cuya función

Un modelo de Workflow es la representación formal de las partes automatizadas

Arquitecturas de Gestión de Workflow [Weske]

Congreso Andino de Computación, Informática y Educación CACIED 2013

1.2 Modelo y Notación del Proceso de Negocio (BPMN 2.0)

El Modelo y Notación del Proceso de Negocio (BPMN 2.0) es un estándar del

Congreso Andino de Computación, Informática y Educación CACIED 2013

Los elementos básicos de modelado BPMN son: evento, actividad, compuerta,

Tabla NN. Elementos básicos de modelado BPMN 2.0

Congreso Andino de Computación, Informática y Educación CACIED 2013

Compuerta Se usa para controlar la divergencia y

Flujo de Se usa para mostrar el orden en que las

Flujo de Muestra el flujo de mensajes entre dos

Congreso Andino de Computación, Informática y Educación CACIED 2013

Mensaje Un mensaje se usa para representar los

Grupo (una Un grupo es una agrupación de elementos

Fuente (OMG, 2011)

1.3 Reglas de Negocio

Desde la perspectiva de TI, las RN son requisitos primordiales del software

Congreso Andino de Computación, Informática y Educación CACIED 2013

Las bases para la formalización de las RN las proporciona el artículo seminal

Las RN han sido objeto de diversas propuestas de clasificación [BRG2007]

En el trabajo de Chaparro (2012), se propone una clasificación basada en el SBVR

Las reglas operativas expresan restricciones que influyen en el resultado de

Congreso Andino de Computación, Informática y Educación CACIED 2013

Figura 1. Clasificación conceptual de las reglas de negocio (Fuente: el autor)

Una regla de derivación genera un hecho derivado a partir de una regla de

Un regla de inferencia produce un hecho derivado como conclusión de inducción

Una regla de cálculo produce un hecho (resultado) derivado mediante la ejecución

Para realizar la propuesta que se describe en este artículo, se utilizó investigación

Congreso Andino de Computación, Informática y Educación CACIED 2013

Se estudió el funcionamiento de varios BPMS, entre ellos Aura Portal y un Motor

Para realizar la propuesta, se profundizó en BPMN 2.0, Reglas de Negocio y

La investigación I+D se aplicó al desarrollo de un prototipo de motor de RN que

3. Enfoque para Separar las RN del Proceso de Negocio

3.1 Análisis del Estado Actual

Congreso Andino de Computación, Informática y Educación CACIED 2013