Lenguaje de dominio específico para la representación de procesos de los negocios

Texto completo

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

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

(3) 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í..

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

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

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

(7) Tabla de contenidos. 2.2.2. VI. 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.

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

(9) Listado de Tablas. VIII. Listado de Tablas Tabla 2-1. Tabla comparativa de compiladores de compiladores. ............................................... 21.

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

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

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

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

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

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

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

(17) 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:.

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

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

(20) 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 metametalenguaje 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..

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

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

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

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

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

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

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

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

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

(30) 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. Producto. Aná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. no. GNU LGPL. SLK. LL(k). 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. no. Desconocida. Yacc++. LR(k) LALR(k). C++, C#. Generado Externo. Cualquiera. no. GNU GPL. YooParse. LR. C++. Externo (YooLex). Cualquiera. no. MIT. /. C#,. or. 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..

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

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

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

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

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

(36) 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:.

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

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

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

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

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