lenguaje de dominio específico para la representación de

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 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/.


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.


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:


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


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


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.


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.


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


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.


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.


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).


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.


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.


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.


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.


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


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" "{"


(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.


EstadoTrabajo:

"estado-trabajo" "{"


(tareas+=Tarea)+


(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" "{"


(accion=AccionAbstracta)?


(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" "{"



(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.


EstadoDecision :

"estado-decisión" "{"


"manejador" ":" claseManejador=JavaIdentifier


(eventos+=Evento)*

"}";

Estado Final: Es empleado para representar el final de la ejecución del proceso.

EstadoFinal :

"estado-final" "{"


(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" "{"


"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.


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.


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:


Transicion :

"transición" "{"


"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.


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.


«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»



</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.


«DEFINE defEstadoAbstracto FOR EstadoAccion»

<node name="«nombre»">


«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>



</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.


«DEFINE defEstadoAbstracto FOR EstadoFinal»

<end-state name="«nombre»">


</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).


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.


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.


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.


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.


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.


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


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.


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.


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".


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.


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"

}}


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:


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


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.


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.


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."

lenguaje de dominio específico para la representación de

Documents