lenguaje de dominio específico para la representación de
TRANSCRIPT
Universidad Central “Marta Abreu” de Las Villas
Facultad de Matemática Física y Computación
Lenguaje de dominio específico para la
representación de procesos de los negocios.
Seminario
Ingeniería del Software
Autor
José David Rodríguez Velasco
Tutor
Lic. Alcides Morales
2008
Dedicatoria
A mis Padres, quienes durante todos estos años confiaron en mí; comprendiendo mis
ideales y el tiempo que no estuve con ellos.
A mi herma linda, que me psicoanaliza sin resultado aparente alguno, pero me hace más
humano en cada sesión. Por ayudarme a enfrentar todos mis molinos.
Dedicatoria II
Agradecimientos
A Raisa, mi tía poderosa, que más que una tía ha sido otra madre, al “Bolo” y compañía
que todos juntos constituyen mi familia teñida.
A Liliam, porque Antes de ti yo no era yo… y que me perdone Jorge Drexler.
Al Gero, Leida y César, que me acompañaron desde pequeño y contribuyeron a que me
gustara tanto la computación.
A mi profesor Frank, al cual le debo mi formación y muchas de las cosas por las que me
siento orgulloso.
A Lester, Ronny y Pável, que siempre han sido un ejemplo a seguir.
A los de siempre: el Moya, Michel, Yosma, Yudith, Erick, Nilsan, Sergi y Caridy, por
haberme enseñado a “gatear”.
Al “Gang of Four”: Alcides, Erifle, Tomy y Michel, por haberme hecho “correr”.
A la Dra. Ana María, que sin su apoyo esta investigación no sería la misma.
Al excelente grupo de profesores de la carrera por lograr hacer de mi un mejor estudiante.
A todos los que confiaron en mí.
Resumen III
Resumen
En esta investigación, resultado de la necesidad de obtener facilidades y herramientas, que
permitan reducir la complejidad inherente al dominio de un problema a informatizar, tiene
como objetivo crear un lenguaje de dominio específico para la representación de procesos
de negocio, más cercana al usuario final, permitiendo la automatización de dichos procesos.
Se abordan términos relacionados con los lenguajes de dominio específicos y la gestión de
procesos de negocio, así como los conceptos fundamentales que los sustentan, tales como:
dominiode aplicación, sintaxis, procesos de negocio y flujo de trabajo, los que constituyen
el sustento teórico de la investigación.
El desarrollo del lenguaje de dominio específico se realizó en tres etapas fundamentales: en
la primera etapa se analizó el dominio de aplicación y se obtuvo como resultado el
conocimiento del dominio del problema; en la segunda se concibió el diseño del lenguaje
utilizando la notación EBNF y en la tercera se implementó el lenguaje con ANTLR y el
framework de Eclipse.
En el trabajo, se muestra por qué los lenguajes de dominio específico y la filosofía de
gestión de procesos de negocio, constituyen en la actualidad dos de las principales líneas de
la ingeniería del software para disminuir el tiempo de desarrollo y se cataloga al ANTLR y
el framework de Eclipse como dos herramientas idóneas para simplificar la complejidad de
implementación de un lenguaje de dominio específico. A la vez, se representa un proceso
de negocio aplicando el lenguaje creado.
Abstract IV
Abstract
The present paper deals with a research aimed at develop a domain specific language to
represent business process, in a closer manner to the end user, allowing the informatization
of such process. This represents the result of the necessity to obtain tools and facilities to
reduce the inherent complexity of the problem domain to computerize. In the research are
boarded terms related to domain specific languages and business process management, as
well the main concepts that embrace its, such as: syntax, application domain, business
process and workflow, conforming the theoretical background of the current investigation.
The domain specific language was developed in three stages. The first stage dealt with the
analysis of the application domain, gathering the domain knowledge of the problem; in the
second was designed the language using the EBNF notation; and in the third the language
was implemented using ANTLR and Eclipse framework.
The work, shows why the domain specific languages and the business process management
constitute two of the main approaches in the software engineer to reduce the develop time
of software construction. Besides, ANTLR and the Eclipse framework can be evaluated as
ideal tools to simplify the develop effort of domain specific languages. At the same time, a
business process is represented through the developed domain specific language.
Tabla de contenidos V
Tabla de contenidos
DEDICATORIA……………… .............................................................................................I
AGRADECIMIENTOS........................................................................................................ II
RESUMEN……… .............................................................................................................. III
ABSTRACT……................................................................................................................. IV
TABLA DE CONTENIDOS ................................................................................................ V
LISTADO DE FIGURAS...................................................................................................VII
LISTADO DE TABLAS .................................................................................................. VIII
INTRODUCCIÓN................................................................................................................. 1
Hipótesis de investigación...................................................................................................3
Objetivo general ..................................................................................................................4
Objetivos específicos ..........................................................................................................4
CAPÍTULO 1. LENGUAJES DE DOMINIO ESPECÍFICO Y GESTIÓN DE PROCESOS DE NEGOCIO.................................................................................................. 5
1.1 Lenguajes de Dominio Específico. ..........................................................................5
1.1.1 Requerimientos de un lenguaje de dominio específico. ...................................6
1.1.2 Ventajas y desventajas de los lenguajes de dominio específico. ......................8
1.1.3 Conceptos relacionados con la implementación de un lenguaje de dominio específico. ........................................................................................................................9
1.2 Gestión de Procesos de Negocio. ...........................................................................11
1.2.1 Definición de términos....................................................................................11
1.2.2 Breve historia de la Gestión de Procesos de Negocio. ...................................13
1.2.3 Ventajas de los sistemas de Gestión de Procesos de Negocio. .......................16
Conclusiones del Capítulo: ...............................................................................................17
CAPÍTULO 2. ANÁLISIS, DISEÑO E IMPLEMENTACIÓN DE UN LENGUAJE DE DOMINIO ESPECÍFICO PARA REPRESENTAR PROCESOS DE NEGOCIO. ............ 18
2.1 Análisis del dominio de aplicación. .......................................................................18
2.2 Diseño e Implementación del Lenguaje de Dominio Específico para representar procesos de negocio. .........................................................................................................19
2.2.1 Selección de las herramientas para la implementación del DSL. ...................19
Tabla de contenidos VI
2.2.2 Gramática y Árbol Sintáctico Abstracto del Lenguaje de Dominio Específico.……………………………………………………………………………..22
2.2.3 Definición de las restricciones semánticas del Lenguaje de Dominio Específico. .....................................................................................................................27
2.2.4 Generación de código. .................................................................................29
Conclusiones del Capítulo.................................................................................................33
CAPÍTULO 3. REPRESENTACIÓN DE UN PROCESO DE NEGOCIO APLICANDO EL LENGUAJE DE DOMINIO ESPECÍFICO CREADO. ................................................ 34
3.1 El proceso de negocio a representar.......................................................................34
3.2 Creación de un nuevo proyecto..............................................................................35
3.3 Creación de la representación un proceso de negocio. ..........................................38
3.4 Representando el proceso de adición de alumnos ayudantes.................................39
3.5 Generando la definición de procesos para JBoss JBPM. .......................................47
Conclusiones del Capítulo: ...............................................................................................49
CONCLUSIONES. .............................................................................................................. 50
RECOMENDACIONES...................................................................................................... 51
BIBLIOGRAFÍA... .............................................................................................................. 52
Listado de Figuras VII
Listado de Figuras
Figura 1-1. Ingeniería ida y vuelta en un sistema GPN. ............................................................... 15
Figura 2-1. Funcionamiento general de un lenguaje de dominio específico. ............................... 20
Figura 2-2. Metamodelo del Árbol Sintáctico Abstracto del DSL creado.................................... 27
Figura 3-1. Diagrama de actividades del proceso de adición de un estudiante como alumno
ayudante. ....................................................................................................................................... 35
Figura 3-2. Ventana de selección del tipo de proyecto a crear. .................................................... 36
Figura 3-3. Ventana para nombrar y definir la localización del proyecto a crear. ....................... 37
Figura 3-4. Estructura de directorios en un proyecto de tipo “uclvbpmdsl Project”. ................... 37
Figura 3-5. Ventana de selección del elemento a crear. ............................................................... 38
Figura 3-6. Ventana para nombrar y definir la ubicación del fichero de representación del
proceso de negocio........................................................................................................................ 39
Figura 3-7. Generación de las definiciones de procesos a partir de las representaciones de
los procesos de negocio en el proyecto......................................................................................... 48
Figura 3-8. Definiciones de procesos. .......................................................................................... 48
Listado de Tablas VIII
Listado de Tablas
Tabla 2-1. Tabla comparativa de compiladores de compiladores. ............................................... 21
Introducción 1
Introducción
Actualmente la mayor parte de la producción de software es aún desarrollada a través de
procesos manuales, comenzando desde cero y mediante trabajos intensivos, comparables a
las labores artesanales. Como resultado, el desarrollo de software es lento, caro y poco
predecible. Esto produce numerosos defectos que terminan provocando problemas de uso,
mantenimiento, seguridad, rendimiento y fiabilidad (P. Clements y L. Northrop 2002; Jack
Greenfield y Keith Short 2007).
Se ha llegado a un punto en el que se requieren mejorar los métodos de producción para
superar esta fase y pasar a la producción de software de una forma más industrializada.
Según (Jack Greenfield y Keith Short 2007) “Como la práctica ha demostrado que el
clásico enfoque artesanal no funciona a gran escala, es beneficioso adoptar y adaptar los
patrones de industrialización que han funcionado en otras industrias”. Entre estos hay que
mencionar el ensamblaje de productos utilizando componentes, la automatización de tareas
rutinarias, formación de líneas de producción y cadenas de suministros así como la
estandarización de procesos, arquitecturas y formatos.
El propósito que persigue la ingeniería de software con esta transformación es convertir el
desarrollo de software en un proceso de ingeniería. Para lograrlo debe existir un conjunto
de metodologías establecidas que puedan ser empleadas de forma sistemática para resolver
nuevos problemas. Así, un proceso de ingeniería puede perfeccionar el desarrollo de
productos por varias vías: reduciendo el tiempo de desarrollo, incrementando la calidad o
aumentando la fiabilidad.
Para posibilitar este paso de perfeccionamiento, manteniendo a la vez la competitividad y
novedad, los desarrolladores deben ser capaces de manejar gran diversidad de técnicas de
diseño, procesos de desarrollo y tecnologías de implementación. Todos estos factores se
suman a la complejidad ya inherente al dominio del problema, agregando nuevas
dificultades asociadas con aspectos metodológicos, organizacionales, económicos y
culturales. Esto unido a los constantes cambios tecnológicos, dificultan mantener fondos
estables y reutilizables de software.
Introducción 2
En términos de la ingeniería de software, disminuir los costos de desarrollo, significa
menores costos, algo que es importante para cualquier empresa; igualmente, mejorar la
fiabilidad de los productos da una ventaja competitiva en cualquier mercado. El mercado
del software en particular es un mercado muy dinámico, donde el factor crítico de
competencia es la velocidad de respuesta a las variaciones tecnológicas (Lau 2005).
Otro punto importante en el proceso de ingeniería de software es la creciente relevancia del
“usuario final”, lo que requiere importantes inversiones para aumentar su accesibilidad
desde tempranas etapas del proceso de desarrollo. Para ello es necesario que los procesos
sean expresables de manera que no requieran conocimientos elevados o especializados. Así
la accesibilidad se convierte en un factor de competitividad, al permitir directamente la
participación de los usuarios para obtener un producto final más cerca de sus
requerimientos.
Existen referencias, aún en etapas tempranas de desarrollo, de algunas propuestas para
lidiar con esta estas necesidades. Intentional Software de la compañía de igual nombre;
Meta-Programming Systems, iniciativa de JetBrains, una empresa desarrolladora de IDEs;
Software Factory, la propuesta de Microsoft como parte del Visual Studio y Model Driven
Architecture (MDA), la visión del Object Management Group (OMG).
La idea central tras todos estos proyectos es enfocar el proceso de desarrollo, normalmente
centrado en el código, en otros tipos de artefactos más resistentes al cambio de tecnologías,
la evolución de los requerimientos y que dichos artefactos sean más comprensibles sin
requerir conocimientos avanzados propios de los desarrolladores de software. MDA, por
ejemplo, propone convertir la modelación (y no la codificación) en el proceso principal y
los modelos (en lugar de los lenguajes generales de programación) en el núcleo central del
desarrollo. Las demás iniciativas mencionadas giran alrededor del uso de los lenguajes de
dominio específico.
Otra de las iniciativas manejadas hoy en día es: separar los procesos de negocio fuera de las
aplicaciones. Como la gestión de los datos y de las interfaces de usuarios se ha
independizado de las aplicaciones en un gran nivel, sucede que gran parte del software es
dedicado a la gestión de procesos de negocio y casos de uso. Por lo que en estos momentos
Introducción 3
resulta más atractivo independizar este componente y encontrar una solución independiente
para los procesos de negocio y los casos de uso. Esto no solo acelera el desarrollo de los
sistemas de información, sino que también ofrece facilidades para el mantenimiento de los
procesos de negocio, lo cual constituye una ventaja.
Asimismo, se señala el hecho de que en procesos típicos de desarrollo, los programadores
más productivos alcanzan cientos de veces el rendimiento de los menos productivos,
mientras que estos últimos los superan en razón numérica, por lo general inversamente
proporcional (P. Clements y L. Northrop 2002; Jack Greenfield y Keith Short 2007; Fowler
2008). Esto significa que en ambientes de desarrollo a gran escala se requieren mejores
formas para que los desarrolladores más talentosos puedan influir más en el incremento del
rendimiento de los demás.
Actualmente, la modelación para el desarrollo de software soporta débilmente la etapa de
concepción de los sistemas, y se centra fundamentalmente en cubrir las necesidades desde
el análisis en adelante. Existen herramientas para facilitar la generación de códigos de
programas, a partir de una descripción informática de un proceso de negocio que se desea
mejorar con su informatización.
Es por todo lo anterior que se considera un problema científico de actualidad la necesidad
de obtener facilidades y herramientas que permitan reducir la complejidad inherente al
dominio de un problema a informatizar, reduciendo el tiempo de desarrollo, haciéndolo
ágil, de respuesta rápida y con control de 360 grados.
Este trabajo está encaminado a ofrecer mayor grado de automatización en la obtención de
soluciones informáticas a partir de los modelos de procesos de negocio, descritos en un
lenguaje de dominio específico para la representación de estos procesos de una manera más
cercana al usuario final.
Hipótesis de investigación
Por medio de un compilador de compiladores es posible crear un lenguaje de dominio
específico que permita la representación de procesos de negocio.
Introducción 4
Objetivo general
Crear un lenguaje de dominio específico para la representación de procesos de negocio,
más cercano al usuario final, que abstraiga el uso de las herramientas existentes para la
gestión de procesos de negocio, y facilite la evolución de las funcionalidades de dicho
lenguaje, permitiendo la automatización de dichos procesos de negocio.
Objetivos específicos
- Identificar en qué consisten los lenguajes de dominio específico y la gestión de
procesos de negocio.
- Seleccionar un entorno de desarrollo, adecuado para la implementación de un
lenguaje de dominio específico.
- Implementar un lenguaje de dominio específico para la representación de procesos
de negocio.
- Representar con el lenguaje de dominio específico implementado un proceso de
negocio.
La tesis quedó finalmente estructurada en 3 capítulos. En el Capítulo 1 se definen los
términos relacionados con los Lenguajes de Dominio Específicos y Gestión de Procesos de
Negocio. En el Capítulo 2 se analizan las tres etapas fundamentales en el desarrollo del
lenguaje de dominio específico creado: en la primera etapa se analiza el dominio de
aplicación, en la segunda se realiza el diseño del lenguaje para representar procesos de
negocio, y en la tercera, la implementación de lenguaje. Finalmente, en el Capítulo 3 se
representa un proceso de negocio, haciendo uso del lenguaje de dominio específico creado,
mediante el cual se describe como hacer uso de los constructores del mismo.
Lenguajes de Dominio Específico y Gestión de Procesos de Negocio. 5
CAPÍTULO 1. LENGUAJES DE DOMINIO ESPECÍFICO Y
GESTIÓN DE PROCESOS DE NEGOCIO.
En este capítulo se definen los términos relacionados con los Lenguajes de Dominio
Específicos y Gestión de Procesos de Negocio, así como los conceptos fundamentales que
los sustentan, tales como: dominio de aplicación, sintaxis, procesos de negocio y flujo de
trabajo.
Acerca de los lenguajes de dominio específico se exponen los diversos requerimientos para
su construcción, las principales ventajas y desventajas de desarrollar software haciendo uso
de ellos, así como también se enuncian los conceptos necesarios en la implementación de
un lenguaje de dominio específico.
Sobre la Gestión de Procesos de Negocio, se enuncian los términos fundamentales y su
definición, se aborda una breve historia de la evolución de la Gestión de Procesos de
Negocio y se plasman los principales beneficios que trae consigo la Gestión de Procesos de
Negocio.
1.1 Lenguajes de Dominio Específico1.
Los programadores hoy en día se encuentran ante el diseño y la construcción de sistemas de
mucha mayor magnitud y complejidad. Los mismos toman años en construirse, con
millones de líneas de código, sobre sistemas distribuidos, en que ningún individuo tiene una
completa comprensión del código (Fowler 2005). Para crear sistemas fiables, escalables y
posibles de mantener, el ingeniero de software puede aplicar una amplia variedad de
herramientas y técnicas, una de ellas es el uso de lenguajes de dominio específico.
Según (Wikipedia 2003) el término lenguaje de dominio específico (DSL) se ha
popularizado en los últimos años en el desarrollo de software para indicar un lenguaje de
programación o lenguaje de especificación dedicado a un problema de dominio, un
problema particular de técnica de representación, y/o una solución técnica particular. El
concepto no es nuevo, lenguajes de programación para fines especiales y todo tipo de
1 DSL, Domain Specific Language en Ingles.
Lenguajes de Dominio Específico y Gestión de Procesos de Negocio. 6
lenguajes modelado/especificación, han existido siempre, pero el término se ha vuelto más
popular debido al incremento del modelado de dominio específico2.
Entonces se define un lenguaje de dominio específico como:
“Un lenguaje de programación designado para un propósito particular, es lo opuesto de
un lenguaje de propósito general, como C o Java, o a un lenguaje de modelado de
propósito general, como UML.” (Wikipedia 2003)
Los lenguajes de dominio específico, pueden ser un vehículo para el análisis formal y los
métodos de optimización; pueden actuar como un puente entre las interfaces visuales y la
computación subyacente; pueden servir para el modelado y prototipos de lenguajes. Pueden
actuar como un andamio para el proceso de ingeniería de software (como ocurre con
lenguajes para la descripción arquitectónica), o pueden ser utilizados directamente (como el
HTML). Fuerzan la separación de intereses y aíslan al usuario de detalles innecesarios. El
resultado es un formalismo, un artefacto concreto que permite la representación,
optimización y análisis de manera que los programas a bajo nivel y bibliotecas no hacen.
Ejemplos de DSL, son las fórmulas de hojas de cálculo de Excel y macros, gramáticas de
YACC para la creación de analizadores sintácticos, las expresiones regulares, Generic
Eclipse Modeling System para la creación de lenguajes basado en diagramas, Csound, un
lenguaje utilizado para crear archivos de audio, y el lenguaje de entrada de GraphViz, un
paquete de software utilizado para diseño gráfico.
1.1.1 Requerimientos de un lenguaje de dominio específico.
A continuación se enuncia un conjunto de requisitos básicos para los DSL en general según
(Kolovos 2006). Además, se hace referencia a los requisitos y principios para el diseño de
lenguajes de programación (Hoare 1973; Wirth 1974), y también trabajos fundamentales
2 DSM, Domain-Specific Modeling en Ingles. Es el proceso de construir un modelo para un dominio específico, el modelado específico de dominio eleva el nivel de abstracción más allá de la programación, especificando la solución al usar directamente conceptos de dominio, DSM Forum. from http://www.dsmforum.com/.
Lenguajes de Dominio Específico y Gestión de Procesos de Negocio. 7
sobre generadores y pequeños lenguajes3 (Cleaveland 1988; A. van Deursen y P. Klint
1998; Wile 2004; M. Mernik; J. Heering; A.M. Sloane 2005).
Algunos de los requisitos para lenguajes de propósito general se aplican directamente a los
DSL. Sin embargo, se sostiene que estos requisitos difieren en cuanto a su importancia
relativa para DSL en comparación con los lenguajes de propósito general.
Los requisitos fundamentales de los DSL son los siguientes:
Conformidad: las sentencias del lenguaje deben corresponder a los conceptos
importantes del dominio.
Ortogonalidad: cada sentencia del lenguaje se utiliza para representar exactamente
un concepto distinto en el dominio.
Integrabilidad: el lenguaje, y sus herramientas, pueden utilizarse de forma conjunta
con otros lenguajes y herramientas con un mínimo esfuerzo. Esto es esencial para
integrar un DSL con otras facilidades utilizadas en el proceso de ingeniería.
Simplicidad: el lenguaje debe ser lo más simple posible, a fin de expresar los
conceptos de interés y apoyar a los usuarios e interesados en sus formas de trabajo
preferidas.
Calidad: el lenguaje facilitará los mecanismos generales para la construcción de
sistemas de calidad.
3 Sinónimo de DSL.
Lenguajes de Dominio Específico y Gestión de Procesos de Negocio. 8
1.1.2 Ventajas y desventajas de los lenguajes de dominio específico.
El uso de un DSL en ingeniería de software implica tanto riesgos como oportunidades. Los
DSL son menos abarcadores que los lenguajes de propósito general, y mucho más
expresivos en el dominio para el que son elaborados. Como resultado, presentan las
siguientes propiedades, cruciales en la industria del software:
Permite que las soluciones sean expresadas en el lenguaje del nivel de abstracción
del dominio del problema, por lo tanto, los expertos del dominio pueden entender,
validar, modificar y a menudo escribir las soluciones (Menzies 2004).
Mejora de la productividad de desarrollo de software. Mientras más fácil sea para
leer un fragmento de código, más fácil es encontrar errores y más fácil aun es
modificar el sistema (Menzies 2004).
Los DSL contienen conocimientos del dominio permitiendo la conservación y
reutilización del mismo.
Permiten la validación a nivel del dominio, permitiendo realizar o facilitando la
realización de propiedades cruciales del software.
Las soluciones escritas en un DSL, son concisas, autodocumentadas (en gran
medida) y pueden ser reutilizadas para diferentes fines (Menzies 2004).
Estas ventajas han llamado la atención de mercados que han evolucionado rápidamente,
algunos de estos mercados son: Internet, comercio electrónico, banco ATM y teléfonos
celulares. Algunas de las compañías que han comenzado a usar los DSL en el proceso de
desarrollo son: Motorola, ATT, Lucent Technologies y Philips. Sin embargo, la mayoría de
los enfoques y técnicas siguen siendo primitivas para llevar a cabo un desarrollo a gran
escala (Fowler 2008).
La razón fundamental por la cual podría no ser conveniente emplear un DSL, seria cuando
no hubiese equilibrio entre los beneficios y el costo de la construcción del DSL o no se
aprecie ninguna de las ventajas de los DSL al problema que se está solucionando.
Algunas de estas desventajas son:
Lenguajes de Dominio Específico y Gestión de Procesos de Negocio. 9
El alto costo de diseñar, implementar y mantener un DSL.
Pérdida de eficiencia, cuando se compara con código escrito a mano.
La dificultad para equilibrar la especificidad del dominio y un lenguaje de propósito
general.
Cacofonía del lenguaje. Los lenguajes son difíciles de aprender, por lo que usar
diferentes lenguajes será mucho más complicado que usar un solo lenguaje, pero los
DSL, tienden a ser limitados y simples, lo que hace que sean fáciles de aprender
(Fowler 2008).
1.1.3 Conceptos relacionados con la implementación de un lenguaje
de dominio específico.
A continuación, se enuncia un conjunto de términos relacionados con la implementación de
un lenguaje de dominio específico, tomados de (Arturo J. Sánchez-Ruíz y Motoshi Saeki
2007).
Aplicación de Software: Una aplicación de software es a menudo un componente
importante de una aproximación para solucionar un problema. En otras palabras, una
aplicación de software es, por lo general, una parte fundamental de la solución a un
problema. Por lo tanto, reconocemos la existencia de problemas cuyas soluciones no
pueden ser expresadas solo como aplicaciones de software (es decir, en ocasiones toma más
de una aplicación de software para solucionar algunos problemas).
Dominio de Aplicación: Intuitivamente, el dominio de aplicación enmarca el problema a
mano. Más exactamente, el dominio de aplicación es caracterizado por los objetos
relevantes (conceptos) y sus relaciones. La importancia está relacionada con el problema en
cuestión, y la decisión de si ciertos objetos y relaciones son relevantes se hace por el equipo
que analiza el dominio en el contexto de un problema que necesita una solución
("Analistas"). Los Dominios pueden ser complejamente grandes, Por ejemplo "Médico",
"Legal". Ellos pueden ser enfocados, por ejemplo: el dominio definido por una colección
personal de CD de música y películas DVD. También pueden ser organizados en alguna
Lenguajes de Dominio Específico y Gestión de Procesos de Negocio. 10
estructura jerárquica. Por ejemplo, el dominio asociado con el problema de encontrar
inmunizaciones para cambiar rápidamente virus humanos sería un subdominio de
"Médico".
Abstracción y Niveles de Abstracciones: Analizando un dominio, en el contexto de
construir aproximaciones para solucionar un problema dado, los analistas practican un
proceso cognoscitivo conocido como abstracción, que consiste en la concentración en "la
esencia" del dominio, ignorando elementos que se consideran superfluos. La abstracción es
practicada cuando los analistas tienen que decidir qué objetos y relaciones son relevantes, y
cuándo ellos documentan y especifican tales objetos y relaciones. Cuando este proceso es
aplicado iterativamente el resultado es una celosía de capas, cada una de las cuales es
referida como un nivel de abstracción.
Lenguaje, Alfabeto, Vocabulario, Sintaxis, Semántica, y Metalenguaje: Un lenguaje
permite que los analistas caractericen dominios, problemas dentro de éstos, y soluciones a
tales problemas. Un lenguaje es definido por su alfabeto, vocabulario, sintaxis, y semántica.
El alfabeto es el conjunto de símbolos usados para construir elementos en el vocabulario. El
vocabulario es el conjunto de "palabras" permitidas. A veces el vocabulario es construido
por la aplicación de “reglas léxicas”, o sea aquellos que definen cómo son construidas las
palabras a partir de elementos del alfabeto.
La sintaxis es el conjunto de reglas que definen todas las "frases" posibles en el lenguaje (es
decir el conjunto de frases sintácticamente correctas), que son construidas con palabras en
su vocabulario. Finalmente, la semántica es la serie de definiciones que establece el
"sentido" de todas las frases posibles sintácticamente correctas dentro del lenguaje.
Note que las reglas y las definiciones asociadas con elementos léxicos, sintácticos y
semánticos, tienen que ser expresadas con la ayuda de lenguajes alternativos, estas
lenguajes son llamados "metalenguajes" porque ellos son usados para definir otros
lenguajes.
Un ejemplo de una regla sintáctica sería la parte de la gramática del Java, usada para definir
estructuras de control. Si una notación muy conocida como “Forma de Backus-Naur”
(BNF) es usada para definir la gramática, entonces BNF sería el metalenguaje usado para
Lenguajes de Dominio Específico y Gestión de Procesos de Negocio. 11
definir la estructura sintáctica del lenguaje. En este caso, encontramos la teoría de lenguajes
formales en el meta-meta nivel. (J. E. Hopcroft y J. D. Ullman 1979)
Hay varias aproximaciones usadas para definir la semántica de lenguajes de programación
(C. A. Gunter 1992), aquí mencionamos sólo dos. En el acercamiento denotacional, la
semántica de una frase en el lenguaje está definida por una función que enlaza tal frase con
una estructura matemática elegida. En este caso, la estructura matemática más la teoría de
conjunto sería el meta-metalenguaje usado para definir la semántica del lenguaje de
programación. En el acercamiento operacional, la semántica de una frase es definida por
una traducción de tal frase a un programa en una máquina abstracta. En este caso, el
lenguaje usado para definir la máquina abstracta y las traducciones constituyen el
metalenguaje usado para definir la semántica del lenguaje de programación. El meta-
metalenguaje sería lo que da el sentido a estas traducciones.
1.2 Gestión de Procesos de Negocio4.
1.2.1 Definición de términos.
El término “Procesos de Negocio” es usado con frecuencia en la actualidad, pero a menudo
para dar a entender cosas diferentes (Pyke 2008). El origen del término, es generalmente
atribuido a Michael Hammer y su trabajo en el área de Reingeniería de Procesos de
Negocio. Cuando Hammer habla acerca de “Procesos de Negocio”, usa el término para
distinguir “Procesos de Negocio” de “Procesos de Manufacturado” o “Procesos Químicos”.
La característica más distintiva de los procesos de negocio es que involucran personas
haciendo trabajos de oficina. El objetivo del trabajo de Hammer era hacer que las personas
terminaran de pensar acerca del trabajo de oficina, organizados a través de líneas
funcionales, y comenzaran a pensar acerca de la cadena de diferentes acciones que deben
acoplar para alcanzar algún objetivo del negocio.
Hammer tuvo éxito en hacer que las personas adoptaran su idea, y actualmente ningún
analista de negocios, intenta mejorar la manera de trabajo en una oficina sin comenzar por
4 BPM, Business Process Management en Ingles.
Lenguajes de Dominio Específico y Gestión de Procesos de Negocio. 12
modelar el proceso. Raramente, algunas personas usan el término procesos de negocio en
contextos que no involucran personas o trabajo de oficina (Pyke 2008).
De las definiciones que hay de procesos de negocio, se prefiere usar la de WfMC5, que es
estable desde hace 10 años.
Un proceso de negocio “es un conjunto de uno o más procedimientos enlazados o
actividades, que conjuntamente alcanzan un objetivo del negocio o modo de acción,
normalmente en el contexto de una estructura organizacional, definiendo roles funcionales
y relaciones”.
A continuación se enuncian las definiciones de “Flujo de Trabajo” y “Definición de un
Proceso”, tomados de WfMC, los cuales tienen estrecha relación con la definición de
“Proceso de Negocio”.
Un Flujo de Trabajo “es la automatización de un proceso de negocio, por completo o una
parte, durante el cual documentos, información o tareas son pasados de un participante a
otro para trabajar, acorde a un conjunto de reglas de procedimientos”.
La Definición de un Proceso “es la representación de un proceso de negocio en una
forma que soporte manipulación automatizada, tales como el modelado, o ejecución por un
sistema gestor de flujos de trabajo. La definición de un proceso consiste en una red de
actividades y sus relaciones, un criterio para indicar el inicio y la terminación del proceso,
e información acerca de las actividades individuales, tales como aplicaciones de la
tecnología de la información y datos, entre otros.”
El glosario de WfMC, no incluye una definición de "Gestión de Procesos de Negocio", pero
sus últimos debates, se han centrado en la siguiente propuesta que resalta el aspecto de
gestión en el término:
La Gestión de Procesos de Negocio (BPM) es “la práctica para desarrollar, ejecutar,
medir el rendimiento y simular Procesos de Negocio, para llevar a cabo el continuo
refinamiento de estos procesos. La Gestión de Procesos de Negocio está en estrecha
relación con el ciclo de vida de la Definición de un Proceso” (Swenson 2008)
5 Workflow Management Collection.
Lenguajes de Dominio Específico y Gestión de Procesos de Negocio. 13
Como tradicionalmente el trabajo de oficina se ha apoyado en la utilización de documentos
en papel y carpetas pasadas de trabajo a trabajo, muchos de los primeros productos de flujo
de trabajo se centraron en el enrutamiento de documentos a través de un grupo de personas.
Sistemas más recientes son un poco más sofisticados, ofreciendo no sólo los documentos
más información estructurada sobre la manipulación, sino también procesamiento complejo
de eventos, manipulación programática de la información, y la posibilidad de intercambiar
información con servicios web y otras fuentes externas de información. Estas nuevas
capacidades permiten a los sistemas de flujo de trabajo integrarse en la moderna
infraestructura de la Tecnología de la Información. Al mismo tiempo, los sistemas de flujo
de trabajo no han olvidado el aspecto humano, que dan a los flujos de trabajo la capacidad
para cerrar la brecha entre el mundo de los negocios y el mundo de la Tecnología de la
Información.
1.2.2 Breve historia de la Gestión de Procesos de Negocio.
Fue en los inicios de la década de los ochenta, que se usó por primera vez el término “flujo
de trabajo”. La mayoría de los primeros sistemas de flujo de trabajo eran orientados a
documentos, es decir, el único propósito del flujo de trabajo consistía en mover una imagen
escaneada de un documento de una persona a otra, a fin de poder realizar alguna acción en
un sistema diferente.
Desde sus comienzos, los sistemas de flujo de trabajo han evolucionado lentamente en
productos que son mucho más funcionales y flexibles, principalmente en el ámbito de una
mayor capacidad de integración, mayor diversidad de plataformas cliente – servidor, y
algunos aspectos básicos en la modelación de procesos y herramientas de monitorización
de procesos.
Sin embargo, en muchos casos, los productos de flujo de trabajo seguían siendo muy
centrados en el documento: el escaneado y gestión de documentos fue un negocio que daba
grandes ganancias de manera regular para muchos de estos vendedores, que no mostraban
visión cuando se trataba de encontrar usos para el flujo de trabajo fuera de enrutamiento de
documentos en torno a una oficina. Esto condujo a que se realizaran ampliaciones por
terceros a productos de flujo de trabajo, ampliaciones que los vendedores de los sistemas de
Lenguajes de Dominio Específico y Gestión de Procesos de Negocio. 14
flujo de trabajo no consideraran importantes, y comenzaran los primeros sistemas “puros”
de flujo de trabajo (los primeros sistemas BPM) que ignoraban el lado centrado en
documentos y eran incapaces de manejar la carga de trabajo, pero mejoraban en términos
de funcionalidad.
Si bien el flujo de trabajo comenzaba en la década de los ochenta, las Aplicaciones de
Integración Empresarial6, o AIE, surgían de forma independiente para la integración de
sistemas a finales de los ochenta y principios de los noventa.
Los sistemas de flujo de trabajo y las AIE estaban separadas durante este período, aunque
ahora son vistos como dos extremos del mismo espectro de integración (Kemsley 2006).
No sólo fueron creados por dos diferentes grupos de vendedores, y basadas en diferentes
tecnologías y estándares, sino que se vendieron a dos diferentes tipos de cliente: el flujo de
trabajo normalmente se vendía a unidades de negocio como soluciones departamentales,
mientras que AIE se vendían a los fabricantes de Tecnologías de Información como un
componente de infraestructura.
A fines de la década de los noventa, los vendedores del flujo de trabajo vieron las ventajas
de las AIE y comenzaron a añadir capacidades de la AIE a sus productos (Kemsley 2006).
Las organizaciones que habían puesto en práctica con rapidez el flujo de trabajo, se dieron
cuenta de que una vez que el proceso se convertía en electrónico, no era posible
supervisarlo. El monitoreo y presentación de informes en los flujos de trabajo nacieron de
la necesidad de comprender qué era lo que el proceso hacía (y no hacía), esto era a menudo
una capacidad altamente personalizada. Después de años de que los clientes elaboraran sus
propias herramientas de monitoreo y de reportes, o utilizaran herramientas de análisis
creadas por terceros, los productos de flujo de trabajo comenzaron a ampliar su capacidad
en este ámbito. Los principios de supervisión en tiempo real crecieron hasta convertirse en
una parte de lo que hoy se conoce como Monitor de Actividad del Negocio7, o MAN. La
6 EIA, Enterprise Application Integration en Ingles. Se refiere a varias técnicas usadas para compartir datos y procesos de negocio en empresas de gran escala.7 BAM, Business Activity Monitor en Ingles.
Lenguajes de Dominio Específico y Gestión de Procesos de Negocio. 15
necesidad de optimizar los procesos de negocio ha empujado más allá del análisis, hasta la
simulación y creación de herramientas de optimización de los procesos de negocio.
Precisamente, según (Pyke 2006) este es el principal aspecto que diferencia un sistema
BPM de los de Flujo de Trabajo: el análisis y habilidad de manejar los procesos. Un
sistema BPM bien definido tiene en su mayoría tres partes (Pyke 2006):
Un motor de ejecución a partir de la definición de un proceso.
Un ambiente de desarrollo, para modelar la definición de procesos y el análisis, con
ingeniería de ida y vuelta (Ver Figura 1-1).
Capacidades de integración empresarial, y aplicaciones basadas en servicios (SOA8)
Figura 1-1. Ingeniería ida y vuelta en un sistema BPM.
Actualmente, existen alrededor de diez grupos que han adoptado la filosofía BPM, entre
ellos están OMG, W3C, OASIS y WfMC, hay siete estándares con un promedio de 150
páginas de especificación (Muehlen 2007). Los sistemas BPM están aumentando
rápidamente en la funcionalidad, y ya funcionan bien en este momento. Esa es la razón por
la que los BPM, es de alta prioridad para las organizaciones, centradas en la mejora de la
eficiencia y potenciación de los sistemas existentes (Miers 2008).
8 Service Oriented Architecture.
Lenguajes de Dominio Específico y Gestión de Procesos de Negocio. 16
1.2.3 Ventajas de los sistemas de Gestión de Procesos de Negocio.
Un sistema BPM ofrece eficiencia, control y agilidad a la empresa que lo aplica de manera
correcta (Cumberlidge 2007). Estas tres áreas claves del beneficio prometido pueden
desglosarse como:
Aumento en la productividad y la eficacia de un sistema: los sistemas BPM
aseguran de que todos los involucrados en el proceso están siempre trabajando en la
tarea de más alta prioridad, lo que acelera el proceso (Huntress 2006; Cumberlidge
2007; Palmer 2007; Smith 2007).
El aumento de la autoridad y cumplimiento del proceso: los usuarios de un sistema
BPM no tienen otra opción que seguir el proceso que el sistema está ejecutando.
Un negocio más ágil, que puede cambiar y adaptarse más rápidamente: debido a que
un sistema BPM es manejado por definiciones de procesos, más que por puro
código, por lo general es más fácil llevar a cabo un cambio en el sistema, y por
tanto, un cambio en el negocio (Pyke 2006; Publications 2007).
Mejora de la utilización de los recursos: los recursos que no están siendo usados
debidamente, son visibles para la gestión, porque todo lo que ocurre en el proceso
puede ser informado (Cumberlidge 2007).
La mejora de la visibilidad de la ejecución de un proceso: los administradores
pueden informar fácilmente sobre todo lo que está en curso para ser procesado
(Cumberlidge 2007).
Previsiones operacionales más exactas: los administradores tienen una buena
visibilidad en la ejecución de un proceso y pueden planear fácilmente su plan de
operaciones(Smith 2007).
Mayor rendimiento de un proceso: un proceso bien optimizado a través del monitor
de procesos en el sistema BPM, corriendo a la máxima eficiencia, significa que se
va a producir más de lo que el proceso está diseñado para producir(Smith 2007).
Lenguajes de Dominio Específico y Gestión de Procesos de Negocio. 17
Menores tiempos del ciclo de un proceso: como todos los involucrados en el
proceso, están trabajando al máximo de eficiencia, el tiempo total que se necesita
para ejecutar el proceso desde el principio hasta el final se reducirá (Smith 2007).
Bajo costo total de un proceso: la reducción del tiempo de ciclo, la mejora de la
calidad, y reducir al mínimo el costo de los insumos de los procesos, garantizan que
el costo total de ejecutar el proceso se reduzca.
Más clientes satisfechos: un sistema BPM garantiza que los clientes obtengan una
mayor calidad del bien o servicio requerido, más rápido y más coherente (Smith
2007).
Conclusiones del Capítulo:
Ha quedado definido lo que constituye el sustento teórico de nuestra investigación, el cual
ha reflejado cómo los DSL y la filosofía BPM constituyen en la actualidad dos de las
principales líneas de la ingeniería del software para disminuir los costos de desarrollo, la
primera a través de la elevación del nivel de abstracción, permitiendo a los analistas del
negocio y programadores expresar conceptos mas cercanos al dominio del problema; la
segunda centrándose en la gestión de procesos de negocio para el desarrollo del software y
el análisis del funcionamiento de estos procesos de negocio para una posterior
optimización.
En el próximo capitulo se expondrá el proceso de construcción del DSL creado para la
representación de procesos de negocio, para uso de los analistas de negocio y
desarrolladores, permitiendo expresar un proceso de negocio de una manera clara y cercana
al usuario final.
Análisis, Diseño e Implementación de un lenguaje de dominio específico para representar procesos de negocio. 18
CAPÍTULO 2. ANÁLISIS, DISEÑO E IMPLEMENTACIÓN
DE UN LENGUAJE DE DOMINIO ESPECÍFICO PARA
REPRESENTAR PROCESOS DE NEGOCIO.
El desarrollo del lenguaje de dominio específico para representar procesos de negocio, se
concibió en tres etapas fundamentales, en la primera etapa se analizó el dominio de
aplicación y se obtuvo como resultado el conocimiento del dominio del problema, en la
segunda se realizó el diseño del DSL para representar procesos de negocio utilizando la
notación EBNF9, y luego en la tercera se implementó con ANTLR y el framework de
Eclipse.
2.1 Análisis del dominio de aplicación.
Actualmente hay una serie de sistemas BPM, tales como Open WFE, Enhydra Shark y
JBoss JBPM, entre los más nombrados. Estos sistemas se encargan de la gestión de
procesos de negocio basándose en Definiciones de Procesos de Negocio. El DSL creado,
ofrece una representación de un proceso de negocio más cercano a los analistas de negocio,
la cual se traducirá a una definición de proceso válida para JBoss JBPM. La selección de
este sistema está fuera del alcance de este trabajo.
La definición de procesos en el JBoss JBPM es a través de un fichero XML con un elevado
nivel de complejidad, el cual presenta dificultades en la interpretación por personas ajenas
al funcionamiento del mismo. Esta razón lleva a la creación del DSL, para representar de
una forma más cercana al usuario final, y de manejo fácil a los desarrolladores.
La representación de un proceso de negocio en el DSL debe permitir aprovechar las
ventajas que ofrece JBoss JBPM y a su vez ser más expresiva. La principal tarea del DSL
es la traducción de la representación de un proceso de negocio a la definición de proceso
en XML utilizada por JBoss JBPM.
La definición de un proceso en JBoss JBPM tiene la estructura de un grafo dirigido,
formado por estados y transiciones. Las transiciones son direccionadas, por lo que los
9 EBNF, Forma de Backus-Naur extendida.
Análisis, Diseño e Implementación de un lenguaje de dominio específico para representar procesos de negocio. 19
estados tienen transiciones entrantes y salientes. Los estados presentan un comportamiento
en dependencia del tipo que sean.
2.2 Diseño e Implementación del Lenguaje de Dominio Específico
para representar procesos de negocio.
El DSL creado está basado en el lenguaje de definición de procesos de negocio de JBoss
JBPM, restringiéndolo para mostrar solo los conceptos relacionados con los procesos de
negocio y haciendo más compresible su sintaxis para lograr un mejor entendimiento por los
analistas del negocio y facilitar a los desarrolladores la creación de una definición de
procesos válida para JBoss JBPM.
El DSL creado fue implementado como pre-procesador, ya que las estructuras del DSL son
traducidas a las estructuras de una definición de procesos en JBoss JBPM y el análisis
semántico está limitado a aquel que fuese realizado por el procesador del lenguaje de
definición de JBoss JBPM.
A continuación se expone el diseño e implementación del lenguaje, se muestran las
herramientas utilizadas en la implementación del DSL en la sección 2.2.1 y luego en la
sección 2.2.2 es especificado el diseño del DSL, en notación EBNF, que también se utiliza
para generar el analizador gramatical del DSL creado. En la sección 2.2.3 se analiza el
chequeo semántico en el DSL y en la sección 2.2.4 se analiza la generación de la definición
de proceso para JBoss JBPM.
2.2.1 Selección de las herramientas para la implementación del DSL.
La implementación de un DSL sigue los principios de un compilador, intérprete o traductor,
siendo este un campo bien definido en la ciencia de la computación (Cleenewerck 2004).
El funcionamiento general de un DSL es el siguiente: el código fuente conforma la entrada
del analizador léxico, este conforma la entrada del analizador sintáctico10 (tokens), luego
10 También conocido como analizador gramatical.
Análisis, Diseño e Implementación de un lenguaje de dominio específico para representar procesos de negocio. 20
este conforma el Árbol Sintáctico Abstracto11 el cual es empleado para hacer el chequeo
semántico y en la generación de código. (Ver Figura 2-1)
Figura 2-1. Funcionamiento general de un lenguaje de dominio específico.
La estructura de un DSL se podría descomponer en cuatro componentes: analizador léxico,
analizador gramatical, analizador semántico y generador de código.
Existen numerosas herramientas (compiladores de compiladores) para automatizar la
construcción de cada una de estos componentes, las principales diferencias entre estas
herramientas son: la estrategia del analizador gramatical, el cual define el tipo de gramática
que describe el lenguaje; el lenguaje en el que se puede generar el analizador sintáctico; la
presencia de analizador léxico; las plataformas de desarrollo en las que son aplicables y el
tipo de licencia de distribución.
La Error! Reference source not found., tomada de (Wikipedia 2008) muestra una
comparación de diferentes herramientas para la construcción de compiladores.
Acerca de estas herramientas (M. Mernik; J. Heering; A.M. Sloane 2005) plantean que la
entrada de estos sistemas es una descripción de varios aspectos del DSL a construir en
términos de meta-leguajes especializados. En dependencia del tipo de DSL, algunos
aspectos importantes son la sintaxis, el cheque semántico, la ejecución, traducción,
transformación y eliminación de errores. Además ocurre que el meta-lenguaje empleado
11 Abstract Syntax Tree (AST) en Ingles.
Análisis, Diseño e Implementación de un lenguaje de dominio específico para representar procesos de negocio. 21
para describir estos aspectos también son lenguajes de dominio específico para el aspecto
particular en cuestión según. Por ejemplo, la sintaxis es usualmente descrita en algún
lenguaje cercano a BNF, el lenguaje más empleado en la especificación de la sintaxis.
ProductoAnálisis gramatical
Languajes generados
Analizador Gramatical
Plataforma de desarrollo
IDE Licencia
ANTLR LL(*)C++, C#, Java, Python
Generado JVM si BSD
Bison LALR, GLR C, C++ Externo Cualquiera no GNU GPL
CppCC LL(k) C++ Generado POSIX no GNU GPL
CUP LALR Java Externo (JLex) JVM no GNU GPL
jacc LALR Java Externo JVM no BSD
JavaCC LL(k) Java Generado JVM si BSD
jay LALR C#, Java Ninguno Cualquiera no BSD
Menhir LR(1) OCaml Generado Cualquiera no QPL
SableCC LALR Java, C Generado Cualquiera noGNU LGPL
SLK LL(k)C, C++, C#, Java
Externo Cualquiera no Propie-taria
SPARK GLR Python Externo Cualquiera no MIT
Spirit LL(k) C++ Interno Cualquiera no Boost
TP Yacc LALR(1) Turbo Pascal Externo Cualquiera si GNU GPL
Yacc (AT&T)
LALR C Externo POSIX noDesco-nocida
Yacc++LR(k) / LALR(k)
C++, C#Generado or Externo
Cualquiera no GNU GPL
YooParse LR C++Externo (YooLex)
Cualquiera no MIT
Tabla 2-1. Tabla comparativa de compiladores de compiladores.
Se decide hacer uso del ANTLR junto al framework de Eclipse con el objetivo de crear un
DSL para representar procesos de negocio y su editor textual como plugin de Eclipse
basado en las siguientes ventajas:
Poderosa estrategia LL(*) del analizador gramatical, que soporta gramáticas mas
naturales, facilitando así su construcción.
Genera código legible por humanos, fácil de incrustar en otras aplicaciones.
Atributos de alcance dinámico que permite la comunicación de reglas distantes.
Análisis, Diseño e Implementación de un lenguaje de dominio específico para representar procesos de negocio. 22
Integra el StringTemplate, un poderoso motor de plantillas diseñado para generar texto
estructurado, como código fuente.
Tiene gran soporte a través del sitio web del proyecto12.
Tiene el código fuente bajo una licencia BSD.
Soporta múltiples lenguajes finales, como Java, C#, Python, Ruby, Objective-C, C, y
C++.
Incluido en el framework de Eclipse para la creación de lenguajes de dominio
específico textuales.
El framework de Eclipse para la construcción de lenguajes de dominio específico está
formado en su mayoría por tres DSL para simplificar el uso del ANTLR. El primer DSL es
para describir la gramática y especificar el metamodelo árbol sintáctico abstracto del
lenguaje que se desea crear. También a partir de esta descripción se genera un editor textual
como plugin de Eclipse para el lenguaje descrito. El segundo DSL es para realizar el
chequeo semántico basándose en el árbol sintáctico abstracto instanciado por el analizador
gramatical. El tercer DSL es para generar código basado en el árbol sintáctico abstracto
instanciado por el analizador gramatical.
2.2.2 Gramática y Árbol Sintáctico Abstracto del Lenguaje de Dominio
Específico.
A continuación se describe el diseño del lenguaje creado a través de su sintaxis en EBNF,
así como el metamodelo del árbol sintáctico abstracto (se define en la sintaxis EBNF),
utilizado en el chequeo semántico y en la generación de la definición de procesos en JBoss
JBPM.
Para una mejor comprensión, se presentan por separado las reglas de definición. Encima de
cada regla está la descripción del concepto del dominio de aplicación.
Definición de Proceso: Una definición de proceso de negocio para JBoss JBPM está
compuesta por un estado inicial, una lista de estados y una lista de acciones para ser
12 www.antlr.org
Análisis, Diseño e Implementación de un lenguaje de dominio específico para representar procesos de negocio. 23
referenciadas en el proceso, que en su conjunto describen el comportamiento de la
ejecución del proceso de negocio.
DefinicionProceso :
"proceso" "{"
"nombre" ":" nombre=STRING
estadoInicial=EstadoInicial
(estados+=EstadoAbstracto)*
(acciones+=AccionDelProceso)*
"}";
Para su mejor comprensión es necesario analizar cada una de las componentes de la
representación de un proceso de negocio.
Estado inicial: Es un tipo de estado utilizado para representar el comienzo de ejecución del
proceso, tiene una lista de eventos y otra lista de transiciones.
EstadoInicial :
"estado-inicial" "{"
"nombre" ":" nombre=STRING
(eventos+=Evento)*
(transiciones+=Transicion)+
"}";
Estado Abstracto: Este concepto no esta presente en el dominio de aplicación del DSL, es
utilizado la implementación del DSL para agrupar en una jerarquía de clases (formando
parte del metamodelo del AST) los estados de tipo EstadoTrabajo, EstadoAccion,
EstadoEspera, EstadoDecision y EstadoFinal, donde estos últimos tienen como superclase
EstadoAbstracto.
EstadoAbstracto:
EstadoTrabajo|EstadoAccion|EstadoEspera|EstadoDecision|EstadoFinal;
Estado de trabajo: Es un tipo de estado que representa una o más tareas a ser ejecutadas
por humanos. Presenta una lista de tareas, una lista de transiciones y otra lista de eventos.
Cuando la ejecución del proceso arriba a este tipo de nodo, se espera a que las tareas sean
completadas por los humanos y se continúa la ejecución del proceso tomando una de sus
transiciones.
Análisis, Diseño e Implementación de un lenguaje de dominio específico para representar procesos de negocio. 24
EstadoTrabajo:
"estado-trabajo" "{"
"nombre" ":" nombre=STRING
(tareas+=Tarea)+
(transiciones+=Transicion)+
(eventos+=Evento)*
"}";
Estado de Acción: Es un tipo de estado que permite a los desarrolladores definir una
acción. Este tipo de estado se utiliza fundamentalmente cuando el desarrollador necesita
escribir código para que el sistema realice alguna acción, pero la lógica en el código es
relevante para el trabajo del analista del negocio y se prefiere que esté representado en el
proceso.
EstadoAccion :
"estado-acción" "{"
"nombre" ":" nombre=STRING
(accion=AccionAbstracta)?
(transiciones+=Transicion)+
(eventos+=Evento)*
"}";
Estado de Espera: Es usado para representar una pausa en la ejecución del proceso,
generalmente para representar el comportamiento de espera por un sistema externo.
EstadoEspera :
"estado-espera" "{"
"nombre" ":" nombre=STRING
(transiciones+=Transicion)+
(eventos+=Evento)*
"}";
Estado de Decisión: Es usado para representar cuando el sistema requiere tomar una
decisión en la ejecución proceso y esta necesita ser representada en la representación del
proceso de negocio.
Análisis, Diseño e Implementación de un lenguaje de dominio específico para representar procesos de negocio. 25
EstadoDecision :
"estado-decisión" "{"
"nombre" ":" nombre=STRING
"manejador" ":" claseManejador=JavaIdentifier
(transiciones+=Transicion)+
(eventos+=Evento)*
"}";
Estado Final: Es empleado para representar el final de la ejecución del proceso.
EstadoFinal :
"estado-final" "{"
"nombre" ":" nombre=STRING
(eventos+=Evento)*
"}";
Transición: Las transiciones especifican la ruta entre los estados. Parten de un estado
origen (donde están definidas) hasta un estado destino.
Transicion :
"transición" "{"
"nombre" ":" nombre=STRING
"hasta" ":" estadoDestino=[EstadoAbstracto|STRING]
(acciones+=AccionAbstracta)*
"}";
Acción: Las acciones están dirigidas a los desarrolladores. Estas permiten a los
desarrolladores ejecutar código java al proceso en su ejecución. Típicamente, las acciones
son usadas cuando se requiere hacer algo de una manera automatizada, que no este al
alcance de la definición del proceso.
Análisis, Diseño e Implementación de un lenguaje de dominio específico para representar procesos de negocio. 26
Accion :
"acción" "{"
(nombrada?="nombre" ":" nombre=STRING)?
tipo=TipoDeAccion
"}";
Evento: Especifican momentos en la ejecución de un proceso y son definidos para los
diferentes tipos de estados, pueden ser de entrada o salida del estado en el cual son
definidos.
Evento :
"evento" "{"
"tipo" ":" tipo=TipoEvento
(acciones+=Accion)
"}";
Estos son los principales constructores del lenguaje creado, como se puede apreciar, cumple
con los requisitos de los DSL, expuestos en el Capítulo 1.
Como se comentó, con la sintaxis del lenguaje se define el metamodelo del Árbol
Sintáctico Abstracto, la Figura 2-2 expone un fragmento de dicho metamodelo, en el cual
están presentes los principales elementos que se definen en el lenguaje.
Análisis, Diseño e Implementación de un lenguaje de dominio específico para representar procesos de negocio. 27
Figura 2-2. Metamodelo del Árbol Sintáctico Abstracto del DSL creado.
2.2.3 Definición de las restricciones semánticas del Lenguaje de
Dominio Específico.
En la implementación del DSL se hace un chequeo semántico para las representaciones de
procesos de negocio, estas restricciones son comunes a todos los procesos de negocio que
puedan representarse con nuestro DSL, y tienen como propósito asegurar que el proceso de
negocio representado pueda transformarse en una definición de proceso válida para JBoss
JBPM.
El chequeo semántico se hace de dos maneras fundamentales, la primera es en la gramática
del lenguaje, y la segunda es en el DSL que provee el framework de Eclipse para definir el
chequeo semántico de un DSL.
El chequeo semántico en la gramática se pone de manifiesto en reglas como la siguiente:
Análisis, Diseño e Implementación de un lenguaje de dominio específico para representar procesos de negocio. 28
Transicion :
"transición" "{"
"nombre" ":" nombre=STRING
"hasta" ":" estadoDestino=[EstadoAbstracto|STRING]
(acciones+=Accion)*
"}";
Una transición solo puede comunicar dos estados, el estado origen (aquel donde este
definida la transición) y el estado final, uno de los estados abstractos definidos en la
representación del proceso.
El resto del chequeo semántico es generado por el framework de Eclipse a partir de la
definición de las reglas semánticas, escritas en el DSL para realizar el análisis semántico.
Las reglas semánticas se definen para las metaclases especificadas en el AST, las cuales
enmarcan el contexto a las que se aplica la regla, luego cuando el analizador gramatical
instancie el AST de una representación un de proceso negocio, se verifican estas reglas.
El siguiente fragmento de código define 3 de las principales restricciones en la
representación de procesos de negocio:
context DefinicionProceso ERROR "Es necesario la definición de" +
"un estado final." :
!(this.estados.select(estado|EstadoFinal.isInstance(estado)).size == 0);
context EstadoInicial ERROR "Solo se permiten eventos de tipo 'salida'" :
!this.eventos.exists(event | event.tipo.tipo == "entrada");
context EstadoAbstracto ERROR "Estado Duplicado: "+ name + "." :
allElements().typeSelect(EstadoAbstracto).select(estado|estado.name==name)
.size == 1;
La primera regla indica que todos los procesos de negocio deben definir un estado final.
La segunda regla indica que en un estado inicial solo se permiten eventos de tipo “salida”.
La tercera regla indica que no pueden existir dos estados abstractos (EstadoTrabajo,
EstadoAccion, EstadoEspera, EstadoDecision, EstadoFinal) con igual nombre.
Análisis, Diseño e Implementación de un lenguaje de dominio específico para representar procesos de negocio. 29
2.2.4 Generación de código.
El propósito de la generación de código es traducir los conceptos de una representación de
un proceso de negocio en el lenguaje definido por nuestro DSL a una definición de proceso
de negocio válida en JBoss JBPM. En esta etapa de traducción no se detectan o reportan
errores de ningún tipo.
La manera en que se debe hacer la traducción es especificada en el DSL del framework de
Eclipse para la generación de código. La generación de código está conformada por un
grupo de plantillas que se definen para las metaclases del AST, cada una de estas platillas
especifican que código generar para cada metaclase una vez instanciado el AST por el
analizador gramatical y hecho el chequeo semántico.
A continuación se enunciarán las plantillas claves para generar una definición de procesos
de negocio en JBoss JBPM a partir del AST instanciado por el analizador gramatical.
«DEFINE defDefinicionProceso FOR DefinicionProceso»
«FILE nombre + ".xml"»
<?xml version="1.0" encoding="iso-8859-1"?>
<process-definition
xmlns="urn:jbpm.org:jpdl-3.2"
name="«nombre»">
«EXPAND defEstadoInicial FOR estadoInicial»
«EXPAND defEstadoAbstracto FOREACH estados»
«EXPAND defAccion FOREACH acciones»
</process-definition>
«ENDFILE»
«ENDDEFINE»
La plantilla defDefinicionProceso define como generar la definición de un proceso de
negocio en JBoss JBPM, y se apoya en las plantillas defEstadoInicial, defEstadoAbstracto
y defAccion.
Análisis, Diseño e Implementación de un lenguaje de dominio específico para representar procesos de negocio. 30
«DEFINE defEstadoInicial FOR EstadoInicial»
<start-state
name="«nombre»">
«EXPAND defEvento FOREACH eventos»
«EXPAND defTransicion FOREACH transiciones»
</start-state>
«ENDDEFINE»
La plantilla defEstadoInicial define cómo generar el estado inicial de la definición de un
proceso de negocio en JBoss JBPM, se apoya en las plantillas defEvento y defTransicion.
El siguiente conjunto de plantillas con nombre defEstadoAbstracto expresan el carácter
polimórfico presentado en las subclases de EstadoAbstracto es decir, el framework de
Eclipse utilizará la plantilla de la subclase en caso de que se requiera generar código para la
superclase (ver plantilla defDefinicionProceso).
«DEFINE defEstadoAbstracto FOR EstadoAbstracto»
«ENDDEFINE»
«DEFINE defEstadoAbstracto FOR EstadoTrabajo»
<task-node name="«nombre»">
«EXPAND defTarea FOREACH tareas»
«EXPAND defTransicion FOREACH transiciones»
«EXPAND defEvento FOREACH eventos»
</task-node>
«ENDDEFINE»
La plantilla defEstadoAbstracto para EstadoTrabajo define como generar un EstadoTrabajo
en la definición de un proceso de negocio en JBoss JBPM, se apoya en las plantillas
defTarea, defTransicion y defEvento.
Análisis, Diseño e Implementación de un lenguaje de dominio específico para representar procesos de negocio. 31
«DEFINE defEstadoAbstracto FOR EstadoAccion»
<node name="«nombre»">
«EXPAND defTransicion FOREACH transiciones»
«EXPAND defAccion FOR accion»
«EXPAND eventDef FOREACH eventos»
</node>
«ENDDEFINE»
La plantilla defEstadoAbstracto para EstadoAccion define como generar un Estado Accion
en la definición de un proceso de negocio en JBoss JBPM, se apoya en las plantillas
defTransicion, defAccion y defEvento.
«DEFINE defEstadoAbstracto FOR EstadoEspera»
<state name="«nombre»">
«EXPAND transitionDef FOREACH transiciones»
«EXPAND eventDef FOREACH eventos»
</state>
«ENDDEFINE»
La plantilla defEstadoAbstracto para EstadoEspera define como generar un estado de
espera en la definición de un proceso de negocio en JBoss JBPM, se apoya en las plantillas
defTransicion y defEvento.
«DEFINE defEstadoAbstracto FOR EstadoDecision»
<decision name="«nombre»">
<handler class="«this.claseManejador»">
</handler>
«EXPAND defTransicion FOREACH transiciones»
«EXPAND defEvento FOREACH eventos»
</decision>
«ENDDEFINE»
La plantilla defEstadoAbstracto para EstadoDecision define como generar un
EstadoDecision en la definición de un proceso de negocio en JBoss JBPM, se apoya en las
plantillas defTransicion y defEvento.
Análisis, Diseño e Implementación de un lenguaje de dominio específico para representar procesos de negocio. 32
«DEFINE defEstadoAbstracto FOR EstadoFinal»
<end-state name="«nombre»">
«EXPAND defEvento FOREACH eventos»
</end-state>
«ENDDEFINE»
La plantilla defEstadoAbstracto para EstadoFinal define como generar un EstadoFinal en la
definición de un proceso de negocio en JBoss JBPM, se apoya en la plantilla defEvento.
«DEFINE defEvento FOR Evento»
<event «EXPAND defTipoEvento FOR this.tipo»>
«EXPAND defAccion FOREACH this.acciones»
</event>
«ENDDEFINE»
La plantilla defEvento define como generar un Evento en la definición de un proceso de
negocio en JBoss JBPM, se apoya en las plantillas defTipoEvento y defAccion.
«DEFINE defTransicion FOR Transicion»
<transition name="«nombre»" to="«estadoDestino.nombre»">
«EXPAND defAccion FOREACH acciones»
</transition>
«ENDDEFINE»
La plantilla defTransicion define como generar una transición en la definición de un
proceso de negocio en JBoss JBPM, se apoya en la plantilla defAccion.
«DEFINE defAccion FOR Accion»<action
«IF nombrada»name="«nombre»"
«ENDIF»«EXPAND defTipoAccion FOR this.tipo»>
</action>«ENDDEFINE»
Finalmente, la plantilla defAccion para Accion define cómo generar una acción en el contexto donde pueda ser definida (EstadoAccion, Transicion o Evento).
Análisis, Diseño e Implementación de un lenguaje de dominio específico para representar procesos de negocio. 33
Conclusiones del Capítulo
De esta manera concluye el desarrollo del lenguaje de dominio específico, en el cual se
analizaron las fases involucradas en el mismo, estas son: el análisis, diseño e
implementación.
Para llevar a cabo la fase de implementación, se definió la gramática, el árbol sintáctico
abstracto, las reglas semánticas y las plantillas de generación de código haciendo uso del
ANTLR y el framework de Eclipse para la generación de un DSL para representar procesos
de negocio y su editor textual. En esta fase, se muestra la potencia y facilidad de uso de
estas herramientas en la creación de lenguajes de dominio específico.
Representación de un proceso de negocio aplicando el lenguaje de dominio específico creado. 34
CAPÍTULO 3. REPRESENTACIÓN DE UN PROCESO DE
NEGOCIO APLICANDO EL LENGUAJE DE DOMINIO
ESPECÍFICO CREADO.
En este capitulo se representa un proceso de negocio tomado del módulo de manejo de
alumnos ayudantes del proyecto nacional SISGNU, para explicar los principales
constructores del lenguaje en esta representación. Además, se muestran las principales
características del editor generado para el lenguaje de dominio específico creado.
3.1 El proceso de negocio a representar.
Actualmente se encuentra en desarrollo por parte de la UCLV un conjunto de módulos para
el proyecto nacional SISGNU, uno de estos, es el modulo de manejo de alumnos ayudantes.
Para el desarrollo de este módulo es necesario informatizar una serie de procesos de
negocio relacionados con el manejo de alumnos ayudantes, uno de ellos, el proceso de
adición de estudiantes como alumnos ayudantes se ha escogido para ser representado en el
DSL creado.
El proceso de negocio a representar, tiene como objetivo la adición de estudiantes como
alumnos ayudantes por parte del usuario del sistema. Este proceso comienza con la
búsqueda de estudiantes aptos para ejercer la ayudantía basándose en la facultad, la carrera
y el año que cursan los estudiantes, de los cuales, uno es seleccionado para ejercer como
alumno ayudante, solo si ya no ejerce como tal.
Es necesario llenar los datos de la ayudantía, estos son el departamento al cual pertenece, el
supervisor del estudiante, la actividad que se realiza, y si esta fuese en un centro fuera de la
universidad se debe especificar el nombre y dirección del centro, así como, el nombre del
coordinador de la ayudantía en el centro. Entonces se procede a registrar los datos del
estudiante, la ayudantía y el centro donde la ejerce (si no es en la universidad) y notificar al
estudiante de su inclusión como alumno ayudante a través de un correo electrónico con los
datos registrados, completando así el proceso en cuestión. La Figura 3-1 muestra el
diagrama de actividades para este proceso de negocio.
Representación de un proceso de negocio aplicando el lenguaje de dominio específico creado. 35
Figura 3-1. Diagrama de actividades del proceso de adición de un estudiante como alumno
ayudante.
3.2 Creación de un nuevo proyecto.
Todas las representaciones de procesos de negocio tienen que estar enmarcadas en un
proyecto de tipo “uclvbpmdsl Project” definido por el editor generado.
Para crear un nuevo proyecto, ejecutar el Eclipse y en el menú File->New elegir la opción
Project, seleccionar “uclvbpmdsl Project” y pulsar el botón “Next”, Figura 3-2.
Representación de un proceso de negocio aplicando el lenguaje de dominio específico creado. 36
Figura 3-2. Ventana de selección del tipo de proyecto a crear.
A continuación se procede a nombrar el proyecto y definir donde se guardarán sus archivos,
Figura 3-3.
Representación de un proceso de negocio aplicando el lenguaje de dominio específico creado. 37
Figura 3-3. Ventana para nombrar y definir la localización del proyecto a crear.
Cada proyecto de tipo “uclvbpmdsl Project” presenta una estructura de directorios, como la
mostrada en la Figura 3-4.
Figura 3-4. Estructura de directorios en un proyecto de tipo “uclvbpmdsl Project”.
La carpeta “src” contiene las representaciones de los procesos de negocio en el proyecto,
estas son de extensión “proc”. La carpeta “src-gen” contiene estas representaciones
convertidas en definiciones de procesos para JBoss JBPM.
Representación de un proceso de negocio aplicando el lenguaje de dominio específico creado. 38
El fichero con extensión “oaw” es el fichero del proyecto, este fichero es el vínculo entre el
editor y el DSL creado. Mediante este fichero es que se pueden transformar las
representaciones de procesos en las definiciones de procesos de JBoss JBPM.
3.3 Creación de la representación un proceso de negocio.
Una vez creado el proyecto, es posible adicionar nuevas representaciones de procesos de
negocio al mismo.
Para adicionar una representación de un proceso de negocio, en el menú File->New elegir
la opción “Other”, seleccionar “uclvbpmdsl Editor File” y pulsar el botón “Next”, Figura
3-5.
Figura 3-5. Ventana de selección del elemento a crear.
A continuación se procede a nombrar el fichero que contendrá la representación del proceso
de negocio (usualmente se utiliza el nombre del proceso que se esta representando) y
definir donde se guardará, Figura 3-6.
Representación de un proceso de negocio aplicando el lenguaje de dominio específico creado. 39
Figura 3-6. Ventana para nombrar y definir la ubicación del fichero de representación del
proceso de negocio.
Una vez creado el fichero que contiene una representación de procesos, estamos en
condiciones de comenzar a representar un proceso de negocio.
3.4 Representando el proceso de adición de alumnos ayudantes.
Lo primero que se debe hacer es declarar que se trata de un proceso, y nombrar que proceso
se esta representando.
proceso {nombre : "Adicion de un estudiante como alumno ayudante"……
}
Según la gramática definida en el Capítulo 2, la representación de un proceso comienza por
la palabra reservada “proceso”, y entre llaves se define un nombre, un estado inicial, un
Representación de un proceso de negocio aplicando el lenguaje de dominio específico creado. 40
conjunto de estados, un estado final y opcionalmente un conjunto de acciones para ser
referenciadas.
El estado por el cual comienza la ejecución del proceso, es el estado inicial, este estado solo
será ejecutado una vez, y cuenta con un conjunto de cero o más eventos, y un conjunto de
una o más transiciones. Para el proceso de adición de estudiantes como alumno ayudante el
estado inicial podría definirse como:
estado-inicial {nombre : "Comienzo del proceso"transición {
nombre : "TransicionName"hasta : "Buscar Estudiantes"acción {
clase:uclv.sisgnu.manejoAA.parametrosBusquedaActionHandler}
}}
El estado inicial representado tiene como nombre “Comienzo del proceso”, no se define
ningún evento y presenta una transición hasta el estado "Buscar Estudiantes", y al tomar
esta transición se ejecutará la acción definida en la clase java
“uclv.sisgnu.manejoAA.parametrosBusquedaActionHandler” para inicializar los
parámetros de búsqueda de estudiantes. Las acciones son empleadas para incluir código
java en la ejecución de un proceso. Cada clase que se desee incluir en una acción debe
implementar la interfaz “org.jbpm.graph.def.ActionHandler”.
Según el proceso que se está representando, la próxima actividad es Buscar Estudiantes,
esta actividad es realizada por humanos, por lo que se usa un estado trabajo para representar
esta actividad.
Un estado de tipo trabajo tiene un nombre, un conjunto de 0 o más tareas, una o más
transiciones y cero o más eventos. En el despliegue de la definición de proceso en JBoss
JBPM, para los estados de tipo trabajo se genera una página web, en la cual las tareas son
formularios que se deberán rellenar por los usuarios. Los datos a rellenar son definidos por
las variables de cada tarea y las transiciones son transformadas en botones donde el texto
del botón es el nombre de la transición.
Representación de un proceso de negocio aplicando el lenguaje de dominio específico creado. 41
Las variables de cada tarea, presentan un nombre, por el cual son identificadas en el
proceso, un tipo de acceso y un texto informativo asociado para brindar una descripción
más exacta al usuario. El tipo de acceso puede ser de lectura; lectura, escritura; lectura,
escritura, requerida; para indicar que es una variable de solo lectura, puede ser modificable
por los usuarios y que el usuario debe rellenar esta variable de forma obligatoria,
respectivamente.
estado-trabajo {nombre : "Buscar Estudiantes"tarea {
nombre : "Parámetros para buscar Estudiantes"variables {
variable {nombre : "strFacultad"acceso : lectura, escritura, requeridotexto : "Introduzca la Facultad del estudiante"
}variable {
nombre : "strCarrera"acceso : lectura, escrituratexto : "Introduzca la carrera del estudiante"
}variable {
nombre : "strAnno"acceso : lectura, escrituratexto : "Introduzca el año que cursa el
estudiante"}
}}transición {
nombre : "Buscar Estudiantes"hasta : "Selección de un estudiante"
}transición {
nombre : "Cancelar Adición"hasta : "Fin del Proceso"
}}
En la búsqueda de estudiantes para adicionar uno como alumno ayudante, se debe rellenar
obligatoriamente la facultad, y opcionalmente se puede reducir la búsqueda especificando
la carrera y el año que cursan los estudiantes, cada una de estas variables son definidas en
la tarea “Parámetros para buscar Estudiantes”, en esta actividad se puede proceder a buscar
los estudiantes o a terminar el proceso de adición, tomando una u otra transición.
Representación de un proceso de negocio aplicando el lenguaje de dominio específico creado. 42
La próxima actividad en el proceso a representar es la Selección del estudiante para
adicionar como alumno ayudante. Esta actividad es realizada por humanos, por lo que se
representa como un estado trabajo.
estado-trabajo {nombre : "Selección de un estudiante"tarea {
nombre : "Resultado de la busqueda"variables {
clase : uclv.sisgnu.manejoAA.busquedaHandler}
}transición {
nombre : "Seleccionar Estudiante"hasta : "Estudiante es Alumno Ayudante"
}transición {
nombre : "Realizar nueva busqueda"hasta : "Buscar Estudiantes"
}}
En la selección de un estudiante, se muestra un conjunto de estudiantes según los
parámetros de búsqueda, de los cuales se puede seleccionar uno para ser alumno ayudante.
En la tarea con nombre “Resultado de la búsqueda”, se muestran estos estudiantes, las
variables dentro del formulario son controladas por la clase
“uclv.sisgnu.manejoAA.busquedaHandler”. Esta clase debe implementar la interfaz
“org.jbpm.taskmgmt.def.TaskControllerHandler”, y cada vez que se cree el formulario se
ejecutara el código definido en esta clase, aquí en esta clase es donde se realiza la búsqueda
según los parámetros definidos en el estado “Buscar Estudiantes”, y se mostraran los
resultados de la búsqueda (varios estudiantes), luego, al tomar una transición, esta misma
clase es la responsable de la adición de las variables al proceso (el estudiante seleccionado).
El usuario tiene la opción de seleccionar un estudiante para su adición como alumno
ayudante o realizar una nueva búsqueda.
Una vez seleccionado un estudiante, este puede ejercer ya como alumno ayudante o no. Si
ejerciese ya como alumno ayudante, es necesario realizar una nueva búsqueda. En cambio
si no es alumno ayudante, se procede a llenar los datos de ayudantía. Esta decisión es
representada por el estado decisión con nombre "Estudiante es Alumno Ayudante".
Representación de un proceso de negocio aplicando el lenguaje de dominio específico creado. 43
Un estado decisión tiene un nombre, un manejador y un conjunto de una o más
transiciones. El manejador es una clase que implementa la interfaz
“org.jbpm.graph.node.DecisionHandler”, la cual es la encargada de tomar la decisión de
qué transición tomar para seguir la ejecución del proceso representado.
La decisión "Estudiante es Alumno Ayudante" se representa como:
estado-decisión {nombre : "Estudiante es Alumno Ayudante"manejador : uclv.sisgnu.manejoAA.estudiantestransición {
nombre : "Si"hasta : "Buscar Estudiantes"
}transición {
nombre : "No"hasta : "Llenar datos de ayudantía"
}}
Si el estudiante seleccionado es alumno ayudante, se tomará la transición hasta el estado
"Buscar Estudiantes", sino se toma la transición hasta el estado “Llenar datos de
ayudantía”.
En la actividad "Llenar datos de ayudantía" el usuario del sistema deberá rellenar los datos
de la ayudantía del estudiante, estos son el departamento al cual pertenece, el supervisor, la
actividad que realiza y si ejerce la ayudantía fuera de la universidad. A continuación se
representa esta actividad.
Representación de un proceso de negocio aplicando el lenguaje de dominio específico creado. 44
estado-trabajo {nombre : "Llenar datos de ayudantía"tarea {
nombre : "Datos de Ayudantía"variables {
variable {nombre : "strDepartamento"acceso : lectura, escritura, requerido texto : "Departamento al cual pertenece"
}variable {
nombre : "strSupervisor"acceso : lectura, escritura, requerido texto : "Supervisor"
}variable {
nombre : "strActividad"acceso : lectura, escritura, requerido texto : "Actividad que realiza"
}variable {
nombre : "blnEjerceEnUniversidad"acceso : lectura, escritura, requerido texto : "Ejerce la ayudantía fuera de la
universidad"}
}}transición {
nombre : "Aceptar"hasta : "Ayudantía fuera de la universidad"
}transición {
nombre : "Cancelar"hasta : "Buscar Estudiantes"
}}
Si la ayudantía del estudiante es fuera de la universidad, se deberá llenar los datos del
centro en el cual ejerce el estudiante sino se procede a guardar los datos de la ayudantía del
estudiante. Esta decisión se representa como:
estado-decisión {nombre : "Ayudantía fuera de la universidad"manejador : uclv.sisgnu.manejoAA.adicion.ayudantiaDecisionHandlertransición {
nombre : "Si"hasta : "Llenar datos del centro de ayudantia"
}transición {
nombre : "No"hasta : "Adicionar estudiante como alumno ayudante"
}}
Representación de un proceso de negocio aplicando el lenguaje de dominio específico creado. 45
En caso que el estudiante ejerza fuera de la universidad, es necesario rellenar el nombre y la
dirección del centro de ayudantía, así como el nombre del coordinador de la ayudantía en el
centro.
estado-trabajo {nombre : "Llenar datos del centro de ayudantía"tarea {
nombre : "Datos del centro"variables {
variable {nombre : "strNombre"acceso : lectura, escritura, requerido texto : "Nombre"
}variable {
nombre : "strResponsable"acceso : lectura, escritura, requerido texto : "Nombre del coordinador"
}variable {
nombre : "strDireccion"acceso : lectura, escritura, requerido texto : "Dirección del centro"
}}
}transición {
nombre : "Aceptar"hasta : "Adicionar estudiante como alumno ayudante"
}transición {
nombre : "Cancelar"hasta : "Llenar datos de ayudantia"
}}
Una vez llenados estos datos se pasa al estado "Adicionar estudiante como alumno
ayudante" a través de la transición “Aceptar”, o a través de la transición “Cancelar” al
estado "Llenar datos de ayudantía".
El estado “Adicionar estudiante como alumno ayudante" es un estado en el cual se lleva a
cabo la adición de un estudiante como alumno ayudante por parte de los servicios web
definidos como parte de la estrategia de centralización de las principales operaciones en
cada modulo del proyecto SISGNU. Para su representación se emplea el estado siguiente:
Representación de un proceso de negocio aplicando el lenguaje de dominio específico creado. 46
estado-espera { nombre : "Adicionar estudiante como alumno ayudante"transición {
nombre : "estudiante adicionado"hasta : "Notificar al estudiante"
}evento {
tipo : entradaacción {
nombre : "Adicionar estudiante"clase :
uclv.sisgnu.manejoAA.adicion.adicionarAAActionHandler}
}}
El estado representa una espera por un sistema externo en la ejecución del proceso. Una vez
terminada la ejecución de los servicios web para adicionar un estudiante como alumno
ayudante, se toma la transición hasta el estado “Notificar estudiante”. El estado contiene un
evento de tipo entrada.
Los eventos son ganchos para ejecutar acciones, y se pueden definir para cualquier tipo de
estado, un evento puede ser de entrada o salida, o sea, el evento ejecuta las acciones antes
(entrada) o después (salida) de procesar el estado donde son definidos. Para el estado en
cuestión se ejecutara la acción "Adicionar estudiante", definida en la clase
“uclv.sisgnu.manejoAA.adicion.adicionarAAActionHandler”, quien se encarga de invocar
los servicios webs correspondientes para adicionar un estudiante como alumno ayudante.
Una vez terminada la adición del estudiante como alumno ayudante, se procede a notificar
al estudiante. Esta actividad es realizada por el sistema, por lo que en su representación se
utiliza un estado acción.
estado-acción {nombre : "Notificar al estudiante"acción {
clase : uclv.sisgnu.manejoAA.adicion.notificacionActionHandler
}transición {
nombre : "estudiante notificado"hasta : "Fin del Proceso"
}}
El estado “Notificar al Estudiante”, tiene una acción, la cual esta definida en la clase
“uclv.sisgnu.manejoAA.adicion.notificacionActionHandler”, esta clase es la encargada de
Representación de un proceso de negocio aplicando el lenguaje de dominio específico creado. 47
enviar un correo de notificación al estudiante, junto con los datos de ayudantía. Luego de
notificar al estudiante, se pasa a al estado final del proceso.
Finalmente, el estado final indica el fin de la ejecución de un proceso, tiene un nombre, y
un conjunto de cero o mas eventos, los cuales solo pueden ser de tipo entrada. La
representación para este estado sigue a continuación:
estado-final {
nombre : "Fin del Proceso"}
Con el estado final, termina la representación del proceso de adicion de un estudiante como
alumno ayudante.
3.5 Generando la definición de procesos para JBoss JBPM.
Una vez terminada la representación del proceso de negocio, se hace necesaria la
generación de la definición del proceso para JBoss JBPM, para un futuro despliegue en el
mismo.
Para generar esta definición basta con presionar el botón derecho del ratón sobre el fichero
del proyecto y en el menú “Run As” seleccionar la opción “oAW”, Figura 3-7.
Representación de un proceso de negocio aplicando el lenguaje de dominio específico creado. 48
Figura 3-7. Generación de las definiciones de procesos a partir de las representaciones de los
procesos de negocio en el proyecto.
Una vez terminada la generación, las definiciones de los procesos representados se
mostrarán la carpeta “src-gen”, Figura 3-8.
Figura 3-8. Definiciones de procesos.
Representación de un proceso de negocio aplicando el lenguaje de dominio específico creado. 49
Conclusiones del Capítulo:
En el capítulo se han plasmado los principales pasos con el editor para crear las
representaciones de los procesos de negocio, y también como obtener a partir de estas
representaciones las definiciones de procesos para la informatización en el JBoss JBPM.
Además, se ha representado el proceso de negocio de adición de un estudiante como
alumno ayudante, a través de la cual se ha descrito como hacer uso de los constructores del
lenguaje creado.
Conclusiones. 50
Conclusiones.
Utilizando un compilador de compiladores (ANTLR) se ha implementado un
lenguaje de dominio específico que permite la representación de procesos de
negocio.
El lenguaje de dominio específico implementado logra abstraer el uso de una
herramienta existente para la gestión de procesos de negocio, el JBoss JBPM,
facilitando la comunicación con los analistas del negocio lo cual pudiese agilizar las
fases de modelado, monitoreo, análisis y optimización, en la ingeniería ida y vuelta
de un sistema BPM.
Los DSL y la filosofía BPM constituyen en la actualidad dos de las principales
líneas de la ingeniería del software para disminuir el tiempo de desarrollo.
El uso del ANTLR y el framework de Eclipse permiten simplificar la complejidad
de implementación de un DSL.
Recomendaciones 51
Recomendaciones
Continuar el desarrollo y prueba de los demás módulos necesarios para integrar el
resultado de este trabajo en una herramienta de mayor alcance.
Basándose en el lenguaje de dominio específico creado, continuar su desarrollo y
obtener un lenguaje grafico para representar los procesos de negocio, que incluya el
chequeo de restricciones en estos procesos haciendo uso de los resultados en la tesis
“Metamodelos para sistemas basados en reglas”.
Fomentar el uso de los DSL para el desarrollo de nuevos sistemas.
Hacer mayor uso de la filosofía BPM en el desarrollo de software en la Universidad
Central de las Villas.
Recomendaciones 52
Bibliografía.
A. van Deursen y P. Klint (1998). "Little languages: little maintenance?" Journal of
Software Maintenance 10:75-92.
Arturo J. Sánchez-Ruíz y Motoshi Saeki (2007). "Do We All Speak the Same Language?"
C. A. Gunter (1992). Semantics of Programming Languages – Structures and Techniques,
MIT Press.
Cleaveland, J. C. (1988). "Building application generators."
Cleenewerck, T. (2004). "Evolution and Reuse of Language Specifications
for DSLs."
Cumberlidge, M. (2007). Business Process Managment with JBoss jBPM, Packt
Publishing.
DSM Forum. from http://www.dsmforum.com/.
Fowler, M. (2005). "Language Workbenches: The Killer-App for Domain Specific
Languages?" from http://martinfowler.com/languageworkbenches.html.
Fowler, M. (2008). "Using Domain Specific Languages."
Hoare, C. A. R. (1973). "Hints on Programming Language Design."
Huntress, J. (2006). "The Current State of BPM Technology: A Taxonomy and Strategy."
J. E. Hopcroft y J. D. Ullman (1979). Introduction to Automata Theory, Languages, and
Computation, Addison-Wesley.
Recomendaciones 53
Jack Greenfield y Keith Short (2007). Software Factories: Assembling Applications with
Patterns, Models, Frameworks, and Tools.
Kemsley, S. (2006). "A Short History of BPM."
Kolovos, D. S. (2006). "Requirements for Domain-Specific Languages."
Lau, L. K. (2005). "Managing Business with SAP: Planning, Implementation, and
Evaluation."
M. Mernik; J. Heering; A.M. Sloane (2005). "When and how to develop domain-specific
languages." ACM Comp. Surv.
Menzies, T. (2004). "Notes on domain-specific languages." from
http://web.cecs.pdx.edu/%7Etimm/dm/dsl.html.
Miers, D. (2008). "BPM—Too Much BP,Not Enough of the M."
Muehlen, M. z. (2007). Business Process Managment Standars.
P. Clements y L. Northrop (2002). Software Product Lines: Practices and Patterns,
Addison-Wesley.
Palmer, N. (2007). "Workflow and BPM in 2007: Business Process Standards See a New
Global Imperative."
Publications, W. (2007). 2007 BPM & Workflow Handbook.
Pyke, J. (2006). "Knowledge Intensive BPM."
54
Pyke, J. (2006). "Workflow - the new BPM?"
Pyke, J. (2008). "BPM in Context, now and in the future."
Smith, H. (2007). Business Process Management: The Third Wave.
Swenson, K. D. (2008). "The Business Value of Workflow and BPM."
Wikipedia. (2003). "Domain-specific language." from http://en.wikipedia.org/wiki/Domain-
specific_programming_language.
Wikipedia. (2008). "Comparison of parser generators." from
http://en.wikipedia.org/wiki/Comparisonofparsergenerators.
Wile, D. (2004). "Lessons learned from real DSL experiments."
Wirth, N. (1974). "On the Design of Programming Languages."