transformación de workflows científicos a modelos de negocio … final.pdf · 2014. 9. 12. ·...
TRANSCRIPT
Universidad Nacional de San Luis
Facultad de Ciencias Físico Matemática y Naturales
Tesis
para optar a la titulación de posgrado correspondiente a la
Maestría en Ingeniería de Software
Transformación de Workflows Científicos
a Modelos de Negocio en BPMN2
utilizando QVT
Lic. Corina Natalia Abdelahad
Directores: Dr. Daniel Riesco (UNSL)
Dr. Carlos Kavka (ESTECO SpA - Italia)
San Luis
2013
Agradecimientos
Habiendo llegado a la culminación de este proyecto, quiero agradecer a todos aquellos que de
una u otra manera me han acompañado en esta etapa dándome su apoyo, consejo y ánimo sin
los cuales no hubiera sido posible lograr este objetivo.
En primer lugar a Dios y a la Mater por sostenerme en todo momento e iluminarme.
A mi familia por su apoyo incondicional en todas mis decisiones.
A mis amigas por soportar mis grandes ausencias, por estar siempre a mi lado y tener
las palabras justas en cada momento.
A mi director Daniel Riesco por confiar en mí dándome la posibilidad de realizar este
trabajo. Por brindarme su asesoramiento siempre y su generosidad a la hora de compartir sus
conocimientos.
A mi co-director Carlos Kavka por su paciencia, dedicación, tiempo y generosidad no
sólo durante el desarrollo de este trabajo de tesis sino durante mi estadía en Italia. Sin Carlos
y Daniel este trabajo y la estadía en Italia no hubieran sido posibles. Estaré eternamente
agradecida.
A la empresa ESTECO SpA por el aporte económico para mi estancia en Italia en la
que pude realizar importantes avances para este trabajo de tesis. Además de abrirme sus
puertas y hacerme sentir parte de ella. En especial le agradezco a Luka, Daniela, Laura y al
grupo de investigación.
A Franco Neri por brindarme su ayuda incondicionalmente.
A mis compañeras de grupo por sus oraciones.
A mis colegas del Área de Programación y Metodología de Desarrollo de Software por
estar dispuestos a ayudarme en todo aquello que estuviera a su alcance.
iii
Índice
Capítulo 1. Introducción 1
1.1. Motivación y Contribuciones……………………………………………. 2
1.2. Trabajos Relacionados ……………………………………………….…. 4
1.3. Objetivos………………………………………………………………… 6
1.4. Organización del Informe……………………………………………...... 7
Capítulo 2. Modelos de Negocio 8
2.1. Introducción …………………………………………………………...... 8
2.2. ¿Qué es BPMN?…………………………………………………………. 9
2.3. ¿Qué es un Proceso de Negocio? ……………………………………...... 11
2.4. Usos generales de BPMN ……………………………………………..... 11
2.5. Elementos de BPMN …………………………………………………… 13
2.6. Flujos de Trabajo (Workflows )…………….…………………………… 31
2.6.1. Sistemas de Gestión de Flujos de Trabajo ………………………… 31
2.6.2. Estándares para modelado de flujos de trabajo……….……………. 32
2.6.3. Flujos de Trabajo Científicos……….………..…………………….. 33
2.6.4. Modelo de referencia de flujos de trabajo…………………………... 34
Capítulo 3. Arquitectura Dirigidas por Modelos 37
3.1. Introducción ………………………………………………………... 37
3.2. MDA………………………………………………………………... 39
3.3. Beneficios de MDA ………………………………………………... 43
3.4. Transformación de Modelos y Metamodelos …..………………….. 44
3.5. Arquitectura en capas ……………………..……………………….. 46
3.6. Estándares involucrados en MDA………………………………….. 48
3.7. QVT ………………………………………………………………... 49
3.7.1. Introducción a QVT …………..………………………………... 49
3.7.2. Visión General ……….………………………………………… 51
3.7.3. Lenguaje Relations …………………………………………….. 53
iv
Capítulo 4. Metamodelos 60
4.1. Introducción………………………………………………………… 60
4.2. Metamodelo BPMN2……………………………………………….. 61
4.2.1. Principales elementos del metamodelo BPMN2……………...... 61
4.2.2. Metamodelo y la Metaclase Process..…………………………... 62
4.2.3. Metaclase Event y sus relaciones……………………………...... 64
4.2.4. Metaclase Activity y sus relaciones…………………………...... 65
4.2.5. Metaclase Gateway y sus relaciones…………………………..... 68
4.2.6. Objetos de datos en el metamodelo..………………………….... 69
4.2.7. Extensiones en el metamodelo..……………………………….... 73
4.3. Metamodelo de ESTECO…………………………………………... 74
Capítulo 5. Transformaciones 79
5.1. Arquitectura ………………………………………………………... 79
5.2. Transformación y Relación Funcional……….……………………... 82
5.3. Reglas definidas para la transformación ….………………………... 85
Capítulo 6. Caso de estudio 103
6.1. Introducción ………………………………………………………... 103
6.2. Un caso de estudio …………………………………………………. 104
Capítulo 7. Conclusiones y Trabajos Futuros 113
7.1. Conclusiones ………………………………………………………. 113
7.2. Trabajos Futuros …………………………………………………... 114
Anexos 116
A. Reglas de Transformación ……………………………………………… 116
B. Código del Caso de Estudio……………………………………………... 137
C. Código generado por la transformación del Caso de Estudio …………... 139
Referencias……………………………………………………………… 143
v
Índice de Figuras
2.1. Ejemplo de un proceso B2B colaborativo ………………………………..
2.2. Ejemplo de un proceso con mínimo detalle ………………………….…...
2.3. Evento de inicio ……………………………………………………...…...
2.4. Evento intermedio ………………………………………………………...
2.5. Evento de fin ……………………………………………………………...
2.6. Actividad ……………………………………………………………..…...
2.7. Tipos de Tareas …………………………………………………………...
2.8. Sub-Proceso colapsado …………………………………………………...
2.9. Sub-Proceso expandido ……………………………………………..……
2.10. Tipos de Call Activity ……………………………………………..…….
2.11. Tipos de Compuertas ……………………………………………………
2.12. Compuerta Exclusiva divergente …………………………………..……
2.13. Compuerta Exclusiva convergente ……………………………………...
2.14. Compuerta Inclusiva divergente ………………………………………...
2.15. Compuerta Paralela ………………………………….…………….…….
2.16. Compuerta Compleja ……………………………………………………
2.17. Compuerta Basada en Eventos ……………………………………..…...
2.18. Objeto de Datos …………………………………………………...…….
2.19. Ejemplo del uso de Objeto de Datos ……………………………….……
2.20. Almacén de Datos ……………………………………………………….
2.21. Dato de Entrada …………………………………………………...…….
2.22. Dato de Salida ………………………………….………………………..
2.23. Reglas de Conexión para los Flujos de Secuencia ………………………
2.24. Flujo de Secuencia ………………………………………………..……..
2.25. Flujo de Secuencia Condicional ………………………………………...
2.26. Flujo de Secuencia por Defecto …………………………………………
2.27. Flujo de Mensaje ………………………………………………………..
2.28. Asociación ………………………………………………………..……..
2.29. Anotaciones de Texto …………………………………………………...
2.30. Asociación de Datos …………………………………………………….
2.31. Ejemplo de utilización de las Asociaciones de Datos …………………..
12
13
14
15
16
16
17
18
18
18
19
19
20
20
21
21
22
22
23
23
24
24
25
25
26
26
26
27
27
27
28
vi
2.32. Pool ……………………………………………………………………...
2.33. Ejemplo de un proceso con más de un Pool …………………………….
2.34. Dos Carriles en un Pool …………………………………………………
2.35. Un Grupo ………………………………………………………………..
2.36. Un Anotación de Texto como Artefacto ………………………………...
2.37. Características de los SGFT ……………………………………………..
2.38. Modelo de Referencia: Componentes e Interfaces .………………..……
3.1. Arquitectura Dirigida por Modelos de la OMG ………………………….
3.2. Transformación de modelos …………………………………………...…
3.3. Transformación de modelos y metamodelos ……………………………..
3.4. Ejemplo de las cuatro capas del metamodelo …………………………….
3.5. Relaciones entre los metamodelos QVT …………………………………
3.6. Declaración de una transformación en QVT-Relations ………………......
3.7. Metamodelo SimpleUML ……………………………………………......
3.8. Metamodelo SimpleRDBMS ……………………………………………..
3.9 Declaración de una relation y dominios checkonly y enforce en QVT-
Relations ……………………………………………………………………….
3.10. Declaración de cláusulas when, where y Pattern matching en QVT-
Relations …………………………………………………...
3.11. Declaración de relaciones top-level y no-top-level en QVT-Relations …
3.12. Creación de objetos usando patrones en QVT-Relations ……………….
4.1. Ilustración de instancias en MOF …………………………………….…..
4.2. Organización de los principales elementos BPMN2 ……………………..
4.3. Algunos elementos relacionados con Process ……………………………
4.4. Clase Event y sus relaciones ………………………………………….…..
4.5. Clase Activity y sus relaciones ……………………………………………
4.6. Clase Task junto con sus tipos y sus relaciones …………………………..
4.7. Clase Sub-Process ………………………………………………………..
4.8. Diagrama de clase para los tipos de compuertas …………………………
4.9. Clase ItemAwareElement …………………………………………………
4.10. Relaciones vinculadas a InputOutputSpecification ………………….….
4.11. Clase DataAssociation …………………………………………………..
4.12. Extensiones en BPMN2 …………………………………………………
28
29
29
30
30
32
34
40
43
46
47
51
53
54
54
55
56
57
59
60
62
63
65
66
67
68
69
70
71
72
74
vii
4.13. Elementos principales del metamodelo ESTECO……………………….
4.14. Elementos relacionados a los Eventos …………………………………..
4.15. Conectores del metamodelo ……………………………………………..
4.16. Modelado de Datos ………………………………………………….…..
4.17. Modelado de Tareas ……………………………………………………..
5.1. Arquitectura de la Transformación …………………………………….…
5.2. Ejemplo de la jerarquía de las cuatro capas del metamodelo …………….
5.3. Correspondencia entre los elementos de ESTECO y los de BPMN2 …….
5.4. Definición de la transformación ………………………………………….
5.5. Elementos involucrados en la relación createProcess ……………………
5.6. Relación para transformar un evento de inicio …………………………...
5.7. Elementos de los metamodelos involucrados en la relación
createSequenceFlowStart2Activity …………………………………………….
5.8. Relación para transformar una tarea ……………………………………...
5.9. Elementos de los metamodelos involucrados en la relación
taskNode2taskBPMN2………………………………………………………….
5.10. Elementos del metamodelo ESTECO para extender las tareas …………
5.11. Relación para transformar un flujo de secuencia ……………………......
5.12. Elementos de los metamodelos involucrados en la relación
createSequenceFlow……………………………………………………………
5.13. Relación para crear propiedades de la tarea Calculator…………………
5.14. Relaciones para crear la propiedad Charset y KeepAlive …………...….
5.15. Elementos de los metamodelos involucrados en las relaciones
propertyCharset y propertyKeepAlive …………………………………………
5.16. Relación para crear el elemento ioSpecification…………………………
5.17. Elementos del metamodelo BPMN2 involucrados en la transformación
de datos …………………………………………………..………………….....
5.18. Relación para transformar los datos de entrada …………………………
5.19. Elementos del metamodelo ESTECO involucrados en la transformación
de datos …………………………………………………………….…………..
5.20. Relación para generar el elemento InputSets y añadirle los DataInputs
5.21. Relación para transformar los datos de salida …………………………..
75
76
76
77
78
81
81
84
86
86
87
88
89
90
90
92
93
94
95
95
96
97
98
99
100
101
viii
5.22. Relación para generar el elemento OutputSets y añadirle los
DataOutputs ……………………………………………………………………
6.1. Entorno modeFRONTIER ………………………………………….…….
6.2. Flujo de trabajo para optimizar un motor de combustión ………………...
6.3. Transformación del nodo de inicio ……………………………………….
6.4. Primera parte de la transformación de tareas …………………………......
6.5. Segunda parte de la relación que transforma las tareas …………………..
6.6. Tercera parte de la relación que transforma las tareas ……………………
6.7. Relación propertyGTSuiteNode …………………………………………..
6.8. Generación de la propiedad Model………………………………………..
6.9. Generación de la propiedad propertyGTSuiteParameterModelInput…......
6.10. Transformación de los datos de entrada …………………………………
6.11. Transformación de los datos de salida …………………………………..
101
104
104
105
106
107
107
108
108
109
111
112
1
Capítulo 1
Introducción
Hoy en día, las actividades de diseño en ingeniería y muchos otros campos de las ciencias
aplicadas requieren la ejecución de modelos computacionales con el fin de simular
experimentos. Este paso es usualmente automatizado a través de la ejecución de los llamados
flujos de trabajo científicos. En términos generales, un flujo de trabajo científico o ingenieril
es un proceso de negocio automatizado utilizado para ejecutar tareas de procesamiento
complejas [1] en las áreas científicas y en aplicaciones ingenieriles. Este tipo de flujos de
trabajo es ampliamente utilizado en las ciencias naturales, simulaciones computacionales,
química, medicina, ciencias ambientales, ingeniería, geología, astronomía, industria
automotriz, aeroespacial y otros campos industriales. Su uso se ha extendido también en las
tareas de optimización. El desarrollo de estos productos industriales complejos se modela
como un ciclo de optimización. Este ciclo incluye un proceso de ingeniería definido en
términos de la colaboración de varios servicios ingenieriles que, por lo general, tienen un gran
intercambio de información [2] [3].
Un gran número de formatos gráficos y de ejecución se encuentran en uso hoy en día.
Aunque los flujos de trabajo científicos o ingenieriles se han utilizado con éxito desde hace
muchos años, la mayoría de las herramientas que se utilizan para definirlos y ejecutarlos no
están basados en tecnologías estándar.
Por otra parte, la compañía ESTECO tiene una amplia experiencia en el ámbito de
flujos de trabajo de ingeniería aplicada en el contexto industrial. La misma ha desarrollado su
propio modelador y motor de flujo de trabajo. Aunque su modelo propietario ha demostrado
ser útil en el contexto de los procesos de ingeniería y cubre las necesidades actuales, la
utilización de un estándar permitirá la construcción de modelos unificados y estandarizados.
La situación es completamente diferente en el área de los procesos de negocio, donde
se han propuesto muchos estándares bien definidos y ampliamente utilizados, tanto para la
representación gráfica como para la ejecución de los mismos. La OMG junto con BPMI
(Business Process Modeling Initiative) han desarrollado la notación BPMN (Business Process
2
Model and Notation) para el modelado de procesos de negocio [4] [5]. BPMN se considera la
notación más comprensible y utilizada para el modelado de procesos de negocio. Además es
una plataforma independiente y define una notación para la definición de los procesos.
Actualmente BPMN es un estándar ISO/IEC 19510:2013. BPMN también permite la
colaboración entre procesos de negocios de distintas organizaciones, es decir permite la
interrelación con otro proceso de negocio independiente que se ejecuta en otra empresa.
El objetivo principal de BPMN es proveer una notación realmente entendible para
todos los usuarios del negocio, desde los analistas hasta las personas del negocio quienes
manejarán los procesos. Por lo tanto, BPMN crea un puente estandarizado para cubrir la
brecha entre el diseño de procesos de negocio y la implementación de éstos. BPMN2 [4] es la
última definición del estándar para modelar procesos de negocios. Éste ha sido desarrollado
teniendo en cuenta algunas limitaciones y dándole mayor importancia a los objetos de datos.
De esta manera se hace posible interpretar y ejecutar directamente los modelos. La definición
de este nuevo estándar permite, por primera vez, extender el uso de flujos de trabajo de
negocios al campo de las ciencias ingenieriles. Sin embargo, uno de los principales obstáculos
para la adopción industrial de estándares es que existe una gran cantidad de flujos de trabajo
existentes actualmente utilizados por la industria que no pueden ser simplemente descartados.
Por otro lado, la Arquitectura Dirigida por Modelos (Model Driven Architecture -
MDA) [6] [7], implementación de la OMG (Object Management Group) para la Ingeniería
Dirigida por Modelos (Model-Driven Engineering- MDE) [8] [9], propone un proceso de
desarrollo de software en el cual la clave son los modelos y las transformaciones entre ellos.
En este proceso, el software es desarrollado construyendo uno o más modelos, y
transformando éstos en otros modelos o hasta llegar a código ejecutable. Teniendo en mente
este objetivo la OMG propone QVT (Query/View/ Transformation), un lenguaje estándar para
expresar consultas y definir transformaciones de modelos. Su especificación depende de otros
dos estándares de la OMG como son MOF y OCL [10]. La utilización de QVT para
especificar transformaciones, aporta reutilización de tecnologías que siguen estándares de la
OMG [10]. Con QVT es posible definir transformaciones genéricas entre metamodelos, de
esta manera cualquier instancia de un metamodelo puede ser transformado en una instancia de
otro metamodelo. QVT se basa principalmente en la definición de un lenguaje para las
consultas (Queries) sobre los modelos MOF, la búsqueda de un estándar para generar vistas
(Views) que muestran aspectos específicos de los sistemas modelados, y la definición de un
lenguaje para la descripción de transformaciones (Transformations) de modelos MOF.
1.1 Motivación y Contribuciones
Tanto los flujos de trabajo científicos como los ingenieriles difieren en muchos aspectos con
los flujos de trabajo de negocios. Por ejemplo, los flujos de trabajo de negocio suelen tratar
con transacciones discretas, en cambio los flujos de trabajo científicos o ingenieriles suelen
3
trabajar con muchas herramientas de software interconectadas, grandes cantidades de datos
con múltiples fuentes de datos y en múltiples formatos. Además, por lo general los servicios
ingenieriles tienen una larga duración de ejecución y dependen del entorno de ejecución.
Incluso si bien, los flujos de trabajo ingenieriles se han utilizado con éxito desde hace tiempo,
la mayoría de las herramientas no siguen un estándar.
Como hipótesis, en este trabajo de tesis se intenta demostrar que es posible que un
modelo de flujo de trabajo ingenieril sea modelado con la nueva versión del estándar de
BPMN2, ya que ésta ha sido desarrollada teniendo en cuenta algunas limitaciones y dándole
mayor importancia a los objetos de datos.
Considerando que existen muchos flujos de trabajo ingenieriles ya diseñados y
utilizados actualmente por la industria que no pueden descartarse. Con el fin de proporcionar
soporte para estos flujos de trabajo, se ha propuesto un método para la transformación de los
flujos de trabajo propietarios de ESTECO existentes a flujos de trabajo estándar BPMN2. Este
enfoque proporcionará un incentivo adicional para que las empresas abandonen las
herramientas de modelado propietarias y comiencen a utilizar tecnologías estándar.
Sin embargo, las transformaciones no son directas. Existen actividades que poseen
propiedades adicionales y requisitos que los procesos de negocios estándares no poseen.
Afortunadamente, BPMN2 ha definido un mecanismo de extensión que permite añadir
construcciones necesarias sin romper el cumplimiento del estándar.
Como parte del método, este trabajo presenta una transformación que permite la
conversión de flujos de trabajo de ESTECO básicos a BPMN2.
La propuesta planteada en el presente trabajo, ha sido publicada en la siguiente revista:
Corina Abdelahad, Daniel Riesco, Carlo Comin, Alessandro Carrara, and Carlos
Kavka "Towards the Standardization of Industrial Scientific and Engineering
Workflows with QVT Transformations”, International Journal On Advances in
Software, Soft13v6n12, 2013.
Además, ha sido aceptada en las siguientes conferencias de ámbito internacional y nacional:
Corina Abdelahad, Daniel Riesco, Carlo Comin, Alessandro Carrara, and Carlos
Kavka, “Data Transformations using QVT between Industrial Workflows and
Business Models in BPMN”, Proceedings of the Seventh International Conference
on Software Engineering Advances ICSEA, IARIA, 2012.
Corina Abdelahad, Daniel Riesco, Carlo Comin, Alessandro Carrara, and Carlos
Kavka, “Hacia una estandarización de workflows científicos e industriales con
BPMN2” 1er Congreso Nacional de Ingeniería Informática /Sistemas de
Información CoNaIISI‟2013, 2013.
4
Corina Abdelahad, Daniel Riesco, Carlo Comin, Alessandro Carrara, and Carlos
Kavka. “Extendiendo BPMN2 para soportar Workflows Científicos de ESTECO”
XV Workshop de Investigadores en Ciencias de la Computación (WICC), 2013.
Corina Abdelahad, Daniel Riesco, Carlo Comin, Alessandro Carrara, and Carlos
Kavka. “Transformación de Workflows Científicos a BPMN2” XIV Workshop de
Investigadores en Ciencias de la Computación (WICC) 2012.
1.2 Trabajos Relacionados
La utilización de flujos de trabajo científicos e ingenieriles para la automatización de procesos
ha sido ampliamente analizada en la literatura [1]. Existen muchas implementaciones
comerciales y de código abierto. Los más utilizados por la comunidad de código abierto son
Kepler [16], Triana [17], Taverna [18], Pegasus [19] y KNIME [20], con nuevos entornos de
trabajo que aparecen continuamente. Sin embargo, todos estos entornos para flujos de trabajo
científicos o ingenieriles se basan en formatos propietarios no estándar. En el campo de
herramientas comerciales, existe muchas opciones como por ejemplo modeFRONTIER [2]
ampliamente utilizado en optimización ingenieril CAD/CAE. Sin embargo, una vez más, ellos
se basan en formatos propietarios.
Los flujos de trabajo científicos y de negocios poseen diferentes características debido
a su objetivo. En [19] se propone llevar flujos de trabajo de negocios y científicos juntos con
el fin de aprovechar las ventajas de ambos. Los autores presentan un enfoque y una
implementación basada en BPEL y Pegasus y demuestran que el enfoque puede ser
beneficioso para los científicos.
Varios trabajos en el campo de la ingeniería de software se relacionan con el concepto
de transformaciones entre modelos, y muchos de ellos utilizan BPMN para modelar procesos
de negocio.
Siguiendo la línea anterior, una transformación modelo a modelo entre PICTURE y
BPMN2 se presenta en [21]. PICTURE es un lenguaje de modelado de procesos de dominio
específico para el sector de la administración pública. La transformación permite modelar
procesos administrativos en PICTURE y obtener modelos BPMN2 para éstos
automáticamente, haciendo posible la implementación de procesos de soporte para ayudar al
gobierno electrónico.
Un ejemplo de aplicación se presenta en [22]. La misma muestra una transformación
automatizada de un modelo de proceso de negocio en un modelo de desempeño
parametrizado, obteniendo así importantes ventajas sobre la fácil personalización y una mejor
automatización.
5
En [23], se presenta la generación de componentes de plataforma de negocios Java
EE6 desde procesos de negocio técnicos modelados con BPMN2. La generación se obtuvo
mediante la realización de tres transformaciones en el contexto MDA, realizadas con QVT
Relations y MOFScript. Este trabajo contribuye mejorando la productividad y la reducción de
los errores de diseño.
Una solución para el modelado de procesos de recorridos clínicos (RC) en términos de
modelos de procesos de negocio estándar es presentada en [24]. Para representar un RC como
un flujo de trabajo de proceso, fue desarrollado un mapeo semántico de alto nivel entre la
ontología RC y la ontología BPMN. Esta investigación muestra cómo un proceso específico
clínico definido con la ontología RC es mapeado a un flujo de trabajo en el estándar BPMN.
Este mapeo permite a los profesionales de la salud modelar un RC utilizando constructores de
modelos familiares a ellos. Una vez listos, los profesionales de la salud pueden transformar
este RC a un modelo de proceso de negocio y aprovechar así las definiciones estándar de los
procesos para representar y optimizar entornos clínicos a través de la incorporación de
herramientas de optimización de procesos.
Por otro lado, en [25] los autores presentan una solución de un caso de estudio de
transformación de modelos BPMN a modelos BPEL [15]. Esa solución implementa un puente
entre dos lenguajes de modelado de procesos de negocio, BPMN y BPEL. La solución
propuesta ha sido implementada utilizando ATL (AtlanMod Transformation Language).
En [26] se presenta una aproximación MDA para la definición de transformaciones
para modelos de procesos de negocio. Estas transformaciones están basadas en el uso de dos
plataformas independientes de flujos de trabajo universales, diagramas de actividad UML 2.0
y BPMN, junto con una plataforma de lenguaje específico, el lenguaje XPDL (XML Process
Definition Language) [39].
En el contexto de transformaciones se puede observar en [27] una transformación de
un diagrama de actividad UML 2.0 a BPEL, en la cual se desarrollan los aspectos de
comportamiento de los servicios web compuestos haciendo uso de un metamodelo MOF para
BPEL 1.1. Los autores trabajaron con un modelo de transformación de procesos de negocio
desde un PIM (Platform Independent Model), creado como un diagrama de actividad UML, a
un PSM (Platform Specific Model), modelado con BPEL4WS. Además introdujeron una
correspondencia entre los elementos de los diagramas de actividad UML y los elementos de
BPEL4WS. Para realizar esta transformación se ha utilizado reglas especificadas en OCL.
En la misma línea, los autores en [28] especifican con el lenguaje ATL la
transformación de un diagrama de actividad UML 2.0 (PIM) a los lenguajes BPEL y Java
(PSM). Analizando la correlación entre los metamodelos a través de un mapeo desde UML a
BPEL4WS. Este trabajo ofrece algunas ideas sobre la definición de mapeo y reglas de
transformación.
6
También se han encontrado trabajos relacionados con las transformaciones de modelos
pero que no están asociados a los procesos de negocio.
En [29] los autores presentan una investigación sobre qué factores tienen un impacto
en el rendimiento de la ejecución de la transformación. Este estudio estima el rendimiento de
una transformación y permite elegir entre las implementaciones alternativas para lograr mayor
rendimiento. Los resultados de este estudio pueden ser utilizados por los implementadores de
los motores de transformación con el fin de mejorar el conjunto de herramientas disponibles
en la actualidad.
Los autores en [30], presentan tres conjuntos de relaciones QVT como un medio de
transformaciones implementados por un método dirigido por modelos para el desarrollo web.
Un conjunto transforma un modelo de entrada de alto nivel en un modelo abstracto específico
para web. Los otros dos conjuntos transforman el modelo abstracto para web en modelos
específicos para plataformas web.
Como puede observarse existen varios trabajos relacionados con las transformaciones
de modelos de procesos de negocio, pero hasta el momento no se ha encontrado un trabajo de
investigación el cual considere BPMN2 como modelador en el contexto de flujos de trabajo
industriales.
1.3 Objetivos
El objetivo de este trabajo es demostrar que es posible modelar procesos ingenieriles con
BPMN2. Además, lograr que un estándar como BPMN2 sea utilizado para procesos
ingenieriles permitiría unificar el modelado para todos los modeladores de procesos
propietarios. Esto permitiría garantizar mayor portabilidad entre las herramientas que soportan
el estándar BPMN2. En cuanto a un objetivo más general, se intenta mostrar que el uso de un
estándar para flujos de trabajo científicos e ingenieriles facilitará la colaboración entre
científicos y diseñadores industriales, mejorando la interacción entre los diferentes campos,
proporcionando así un vocabulario común para que los ingenieros interpreten adecuadamente
cualquier modelo científico e ingenieril.
Si bien la empresa ESTECO está actualmente trabajando para soportar el estándar, con
el fin de garantizar soporte para los flujos de trabajo existentes, se ha hecho necesario llevar a
cabo una transformación desde el metamodelo de ESTECO al metamodelo BPMN2. Esta
transformación permite la conversión de la mayoría de los flujos de trabajo industriales de
ESTECO a BPMN2 consintiendo su ejecución en motores BPMN2, con las debidas
extensiones para soportar las propiedades específicas de los flujos de trabajo de ESTECO.
Para lograr este objetivo es necesario alcanzar las siguientes metas:
Metamodelo de ESTECO en Ecore definido.
7
Correspondencias entre los elementos del metamodelo de BPMN2 y los
elementos del metamodelo de ESTECO establecidas.
Transformación utilizando QVT entre el metamodelo ESTECO y BPMN2
especificada.
1.4 Organización del Informe
Este trabajo presenta una transformación para constructores seleccionados de un flujo de
trabajo de ingeniería industrial al estándar BPMN2, con el fin de presentar un método válido
para realizar una conversión de un flujo de trabajo a un estándar bien definido. En el presente
trabajo, se consideran también las transformaciones de los elementos más complejos basados
en extensiones de BPMN2.
A continuación se presenta la organización de este trabajo. En el capítulo 2 se
describen los Modelos de Negocio, se introducen los conceptos básicos de la notación BPMN
y se identifican los elementos que forman parte de un proceso de negocio. En el capítulo 3 se
muestran los principales conceptos relacionados a la Ingeniería Dirigida por Modelos (MDE)
y a la propuesta Arquitectura Dirigida por Modelos (MDA). Además se muestran los
principios que sustentan MDA, así como los tipos de modelos que la comprenden. También se
introduce la transformación de modelos, además se muestran los estándares involucrados a
MDA poniendo énfasis en el lenguaje de transformación de modelos QVT. En particular se
muestra QVT-Relations. En el capítulo 4 se muestran los metamodelos BPMN2 y ESTECO
utilizados en este trabajo. En el capítulo 5 se detalla paso a paso como ha sido la construcción
de la transformación, utilizando el lenguaje QVT, de ESTECO a BPMN2. En el capítulo 6 se
presenta un caso de estudio junto con una explicación de los resultados de la transformación
en términos de elementos XML. Finalmente se presentan las conclusiones y trabajos futuros.
8
Capítulo 2:
Modelos de Negocio
Hoy en día existen muchos estándares bien definidos y ampliamente utilizados, tanto para la
representación gráfica como para la ejecución de los modelos. BPMN es considerada la
notación más comprensible y utilizada para el modelado de procesos de negocio. En este
capítulo se presentan dos pilares fundamentales para este trabajo. En primer lugar se presenta
el concepto de BPMN (Business Process Model and Notation), sus usos generales y se da una
breve introducción a sus elementos más importantes [4], con los cuales se pueden modelar
cualquier proceso de negocio. En segundo lugar se introduce el concepto de flujo de trabajo,
flujos de trabajo científicos, así como la descripción de los sistemas de flujo de trabajo
estandarizado por la WfMC (Workflow Management Coalition), el modelo de referencia que
estandariza los conceptos junto con su arquitectura, y la estrecha relación que mantiene con la
gestión de procesos de negocio.
2.1 Introducción
En la última década, los procesos de negocio han adquirido gran popularidad, y derivado de
ello han surgido diversos estudios al respecto. Un proceso de negocio es un conjunto de
actividades coordinadas, las cuales están diseñadas para producir una salida específica, ya que
su objetivo está bien definido. Su modelado es un área de interés para los analistas, quienes
definen o redefinen los procesos; para los desarrolladores, los cuales son los responsables de
implementar los procesos; y para los gerentes quienes monitorean y gestionan los procesos.
Por otro lado, una comprensión de como es el flujo de un proceso asegura eficiencia y
calidad en el proceso. El objetivo principal del modelado de procesos de negocio es la
definición de cómo será el flujo del proceso. Para el modelado de procesos de negocio es
necesario responder las siguientes preguntas [31]:
¿Cuál es el resultado del proceso de negocio?
¿Qué actividades se llevan a cabo dentro del proceso de negocio?
¿Cuál es el orden de las actividades?
¿Quién lleva a cabo las actividades?
9
¿Qué documentos se intercambian en el proceso?
¿Cuán seguro es el proceso, y cómo puede ser extendido en el futuro?
Un eficiente proceso de modelado requiere un método que provea un enfoque bien
estructurado y controlado. Además es importante a la hora de modelar un proceso de negocio
poder utilizar una herramienta independiente de la implementación, y por lo tanto, poder
utilizar la especificación del proceso de negocio para diferentes plataformas. Varios métodos
han sido desarrollados a lo largo de los años. BPMI (Business Process Modeling Initiative)
junto con la OMG (Object Management Group) han desarrollado la notación BPMN para el
modelado de procesos de negocio [4] [5]. BPMN se considera la notación más comprensible y
utilizada para el modelado de procesos de negocio. Ésta define una notación para la definición
de procesos de negocio. BPMN también permite la colaboración entre procesos de negocios
de distintas organizaciones, es decir permite la interrelación con otro proceso de negocio
independiente que se ejecuta en otra empresa. BPMN 2.0 es la última definición del estándar
BPMN para modelar procesos de negocios. Éste ha sido desarrollado teniendo en cuenta
algunas limitaciones y dándole mayor importancia a los objetos de datos persiguiendo el
objetivo de poder interpretar y ejecutar directamente los modelos. Esta nueva definición del
estándar permite, por primera vez, la posibilidad de extender el uso de flujos de trabajo del
ámbito de procesos de negocio al ámbito de la ingeniería [32].
Un flujo de trabajo se define como la automatización total o parcial de un proceso de
negocio, durante el cual se intercambian documentos, información o tareas de acuerdo a un
conjunto de reglas establecidas [33]. El modelo que define la arquitectura para esta
automatización por medio de sistemas de flujos de trabajo ha sido definido por la WfMC [39].
Los flujos de trabajo ingenieriles, que comparten muchas propiedades con los conocidos
flujos de trabajo científicos, son muy utilizados en la industria actual.
Un flujo de trabajo industrial es un proceso de negocio automatizado, usualmente
utilizado para ejecutar tareas de procesamiento complejas que requiere muchas características
que la mayoría de los modelos de procesos de negocio no soportan actualmente [34]. Este tipo
de flujos de trabajo son ampliamente utilizados en las ciencias naturales, las simulaciones
computacionales, la química, la medicina, las ciencias ambientales, la ingeniería, la geología,
la astronomía, la industria automotriz y aeroespacial, entre otros campos.
La integración con plataformas del tipo Arquitectura Orientada a Servicios (Service
Oriented Architecture - SOA) y sistemas de Computación en las Nubes (Cloud Computing) es
esencial en el contexto de flujos de trabajo industriales, una característica que no es manejada
de modo adecuado con los típicos flujos de trabajo de negocio [1] [35].
2.2 ¿Qué es BPMN?
La Gestión de Procesos de Negocio (BPM) da apoyo para que los procesos de una
10
organización sean más flexibles y receptivos a los cambios. BPM es una disciplina, que
combina las capacidades del software con la experiencia del negocio para acelerar la mejora
de los procesos y facilitar la innovación del negocio. Los estándares para BPM dan soporte a
la organización para aprovechar el poder del cambio a través de sus procesos de negocio,
utilizando una Arquitectura Orientada a Servicios (SOA) para acomodarse rápidamente a los
cambios del negocio [37].
BPMI junto con la OMG han desarrollado las últimas versiones del estándar BPMN.
El objetivo principal de BPMN es proveer una notación realmente entendible para todos los
usuarios del negocio, desde los analistas que crean el borrador inicial de los procesos, los
desarrolladores responsables de la implementación que llevará a cabo dichos procesos, y por
último, las personas de negocio quienes manejaran y supervisarán los procesos. Por lo tanto,
BPMN crea un puente estandarizado para la brecha entre el diseño de procesos de negocio y
la implementación de procesos. BPMN asegura que lenguajes diseñados para la ejecución de
procesos de negocio, tal como WS-BPEL (Web Services Business Process Execution
Language), puedan ser visualizados con una notación orientada a los negocios [4].
La intención de BPMN es estandarizar la notación y modelado de un proceso de
negocio frente a muchas diferentes notaciones de modelado y puntos de vista. Para esto,
BPMN provee un medio de comunicación entre los procesos y los usuarios del negocio,
implementadores del proceso, clientes y proveedores [4].
BPMN es una notación gráfica que específica que pasos se realizan en un proceso de
negocio, desde su inicio hasta el fin. La notación especifica cuál es la secuencia de las
actividades en un proceso, junto con los mensajes que las atraviesan o transitan entre los
distintos participantes que puede poseer el proceso.
En el 2001, BPMI comenzó a desarrollar BPML (Lenguaje de Modelado de Procesos
de Negocio, un lenguaje XML de ejecución de procesos) y surge así la necesidad de una
representación gráfica. Las personas involucradas en ese momento decidieron que una
notación orientada hacia las necesidades del usuario era necesaria, es decir que no se buscaba
una notación que represente el lenguaje de ejecución. Luego de más de dos años de trabajo el
grupo desarrolló BPMN 1.0 [15]. BPMN tenía dos objetivos contradictorios, por un lado
proveer una manera sencilla de utilizar la notación de modelado de procesos, accesible a los
usuarios empresariales; y por el otro lado ofrecer facilidades para traducir los modelos a una
forma ejecutable tal como BPEL [37]. Además perseguía los objetivos de [36]:
proveer una notación fácilmente entendible por todos los usuarios del negocio,
desde los analistas de negocio hasta la gente propia del negocio,
crear un puente estandarizado entre el diseño del proceso de negocio y su
implementación,
asegurar que los lenguajes para la ejecución de procesos de negocio puedan ser
visualizados con una notación común.
11
En mayo de 2004, fue lanzada al público la especificación 1.0 de BPMN. Desde
entonces, más de 50 compañías han desarrollado implementaciones del estándar. En febrero
de 2006 la especificación 1.0 fue adoptada como un estándar de la OMG (luego de que BPMI
se incorporará a la OMG).
Los miembros de la OMG, a través de sus conocimientos y experiencias con respecto
a muchas notaciones existentes, buscaron consolidar las mejores ideas de estas notaciones
divergentes en una notación estándar única [4]. En febrero de 2008, la OMG publicó la
versión BPMN 1.1. La mayoría de los cambios en la versión 1.1, esclarecieron el documento
de la especificación en sí, haciendo su significado más explícito. Sin embargo, pocos cambios
gráficos fueron realizados a BPMN en la versión 1.1. La OMG pronto publicaría la versión
1.2. Esta versión no incluyó cambios significativos en el aspecto gráfico; los cambios fueron
solamente de redacción [37].
Actualmente se encuentra la versión 2.0 de BPMN. Esta última definición ha sido
desarrollada tomando como uno de sus objetivos la superación de las limitaciones que
impedían su uso en aplicaciones científicas y de ingeniería [4] [32]. Es precisamente la
definición de este nuevo estándar que permite por primera vez la posibilidad de extender el
uso de flujos de trabajo del ámbito de procesos de negocio al ámbito de la ingeniería. Esta
versión da mayor importancia a los objetos de datos persiguiendo el objetivo de poder
interpretar y ejecutar directamente los modelos.
2.3 ¿Qué es un Proceso de Negocio?
Un proceso describe una secuencia o flujo de actividades de una organización con el objetivo
de llevar a cabo un trabajo.
Como se ha mencionado anteriormente, un proceso de negocio es un conjunto de
actividades coordinadas, las cuales están diseñadas para producir una salida específica, ya que
su objetivo está bien definido. Las actividades contribuyen colectivamente a lograr los
objetivos de una organización. Los procesos de negocio de una organización se registran y se
publican en manuales de procedimientos, diagramas de flujo y hasta de manera oral. Son la
base operativa de una empresa y el éxito de la misma depende fuertemente de la eficiencia y
eficacia con que estos sean gestionados. Una mala gestión del proceso puede ocasionar altos
costos, baja productividad y tiempos de respuesta altos. Todo proceso de negocio interesante
puede involucrar una intervención humana [37].
2.4 Usos generales de BPMN
Pueden existir múltiples niveles de diagramas, dependiendo de la metodología utilizada para
el desarrollo de los modelos. Sin embargo, se debe tener en cuenta que BPMN es
12
independiente de cualquier metodología específica de modelado de procesos.
El modelado de procesos de negocio persigue el objetivo de comprender que es lo qué
realiza una organización, quién lo realiza y cómo la realiza. Además es utilizado para
comunicar una amplia variedad de información a diferentes públicos, analistas, diseñadores,
arquitectos, etc. Un modelo de proceso de negocio, es una red de objetos gráficos
comprendida por actividades y flujos que definen el orden de ejecución.
BPMN está diseñado para cubrir muchos tipos de modelos y permite la creación de
una parte del proceso como así también del proceso de negocio completo, en diferentes
niveles de abstracción [36]. BPMN proporciona a las organizaciones la capacidad de definir y
comprender sus procesos de negocio internos y/o externos a través de un Diagrama de
Procesos de Negocio. En muchas situaciones, para la ejecución de un proceso, es necesaria la
colaboración de organizaciones externas al proceso, BPMN permite, de manera clara,
entender cómo se realiza esta comunicación entre las distintas organizaciones. A este tipo de
procesos se lo denominan Procesos de Negocio a Negocio (Business to Business – B2B)
Colaborativo.
Un proceso B2B colaborativo muestra las interacciones entre dos o más
organizaciones de negocio. Para este tipo de procesos los diagramas son utilizados para
mostrar una vista global de los mismos. Es decir, que no tienen la perspectiva de un
participante en particular, sino que muestran las interacciones entre los participantes. La
Figura 2.1 muestra un ejemplo de un proceso colaborativo.
Las actividades para los participantes de la colaboración pueden ser consideradas
"puntos de contacto" entre los participantes, es decir que el proceso define las interacciones
que son visibles para el público por cada participante. Por lo general cuando se está
modelando la comunicación entre dos o más organizaciones, no se muestran todas las
actividades ni el detalle de ellas [36].
Figura 2.1: Ejemplo de un proceso B2B colaborativo
Un proceso de negocio interno debería generalmente focalizarse en el punto de vista
de una única organización. Aunque en los procesos internos por lo general se muestran
interacciones con participante externos, en ellos sólo se definen las actividades que no suelen
ser visibles al público y por lo tanto, son actividades privadas. Si se utilizan carriles
Pacie
nte
Enviar
requerimiento
al doctor
Recibir
respuesta
Enviar
Síntomas
Recibir
prescripción
Consultori
o
Médic
o
Recibir
requerimiento Enviar
respuesta
Recibir
Síntomas
Enviar
prescripción
13
(swimlanes) entonces un proceso de negocio interno estará contenido dentro de un sólo pool.
Los flujos de secuencia de los procesos están contenidos dentro de un pool y no pueden cruzar
las fronteras del pool. Los flujos de mensaje pueden cruzar la frontera del pool para mostrar
las interacciones que existen entre los diferentes procesos de negocio internos. De esta
manera, un sólo diagrama de proceso de negocio puede mostrar múltiples procesos de
negocios privados [36]. Más adelante se discuten los carriles, pools y flujos.
La Figura 2.2 muestra como en un diagrama de proceso de negocio se pueden observar
distintos niveles de detalle. Estos niveles dependen de la metodología utilizada para el
desarrollo del modelo y BPMN es independiente de cualquier metodología.
Figura 2.2: Ejemplo de un proceso con mínimo detalle
2.5 Elementos de BPMN
Uno de los objetivos para crear y desarrollar BPMN era construir un mecanismo simple y
comprensible para la creación de modelos de Procesos de Negocio, además de ser capaz de
manejar la inherente complejidad de los procesos de negocio. Así surge la necesidad de
organizar los aspectos gráficos de la notación en categorías específicas. Es decir que un
elemento clave de BPMN es la elección de formas e íconos utilizados para los elementos
gráficos identificadas en la especificación. La intención fue crear un lenguaje visual estándar
que todos los modeladores de procesos puedan reconocer y entender. BPMN proporciona un
pequeño conjunto de categorías para que el lector de un diagrama BPMN pueda reconocer
fácilmente los tipos básicos de elementos y entender el diagrama. Dentro de las categorías
básicas, se puede añadir información para soportar requerimientos de complejidad sin cambiar
radicalmente el aspecto del diagrama.
Las cinco categorías básicas de elementos son:
1. Objetos de Flujo (Flow Objects)
2. Datos (Data)
Clie
nte
Pro
ceso
de P
ed
ido
Recibir
pedido
+
14
3. Objetos de conexión (Connecting Objects)
4. Carriles (Swimlanes)
5. Artefactos (Artifacts)
Objetos de flujos
Los objetos de flujos son los principales elementos gráficos que definen el
comportamiento de un proceso de negocio. Existen tres tipos de objetos:
Eventos (Events)
Actividades (Activities)
Compuertas (Gateways)
Eventos
Un evento es algo que sucede durante el curso de un proceso de negocio. Los eventos
afectan el flujo de los procesos y generalmente tiene una causa (disparador) o un impacto o
resultado. Los eventos se utilizan en distintas partes del proceso de negocio, pueden mostrar
el comienzo de una actividad, el fin de una actividad, el cambio de estado de un documento,
un mensaje que llega, la interrupción de un proceso, etc. BPMN ha restringido el uso de
eventos para incluir sólo los tipos de eventos que afectan el flujo o tiempo de las actividades
de un proceso.
Los eventos pueden ser de tres tipos:
Evento de inicio
Evento intermedio
Evento de fin
Evento de Inicio
Como su nombre lo indica, un evento de inicio indica donde un proceso comenzará.
Este tipo de evento da inicio al proceso, por lo tanto, no tendrá ningún flujo de secuencia
entrante, es decir que ningún flujo de secuencia puede entrar a un evento de inicio. La Figura
2.3 muestra la representación de un evento de inicio.
Figura 2.3: Evento de inicio
Existen diferentes tipos de eventos de inicio para indicar las diversas circunstancias
15
que pueden disparar el comienzo de un proceso. Estas circunstancias pueden ser la llegada de
un mensaje o un tiempo determinado, como fecha y hora en la cual debe comenzar el proceso.
A estas circunstancias se las llaman factores desencadenantes. Todos los eventos BPMN
fueron diseñados para tener un centro abierto de manera tal de diferenciar los diferentes tipos
de disparadores que pueden suceder.
Evento Intermedio
Como su nombre lo indica, el evento intermedio indica que algo sucede/ocurre
después de que el proceso ha comenzado y antes de que termine el mismo. Este tipo de evento
afectará el flujo del proceso y por lo general se los pueden ver entre las actividades. También
un evento intermedio puede interrumpir el procedimiento normal de una actividad.
Los eventos intermedios se puede utilizar para:
mostrar los mensajes que deben ser enviados, o recibidos desde otra entidad de
negocios en el proceso, o desde la misma entidad,
mostrar retrasos dentro del proceso,
interrumpir el flujo normal a través de manejo de excepciones, o
mostrar el trabajo extra necesario para la compensación.
La Figura 2.4 muestra la representación gráfica de un evento intermedio.
Figura 2.4: Evento intermedio
Existen diferentes tipos de eventos intermedios, cada uno con su propia representación
gráfica. Cada tipo de eventos intermedios pueden lanzar o atrapar el evento. Algunos de ellos
pueden ser: tiempo, mensaje, señales, error, cancelación, etc.
Evento de Fin
Como su nombre lo indica, el evento de fin indica donde un proceso finalizará, o más
específicamente, donde un "camino" dentro de un proceso termina1. Este tipo de evento da fin
al proceso, por lo tanto, no tendrá ningún flujo de secuencia saliente, es decir que ningún flujo
de secuencia puede salir de un evento de fin. La Figura 2.5 muestra un evento de fin.
1 Cuando se modelan threads se hace referencia a “caminos”
16
Figura 2.5: Evento de fin
Existen diferentes tipos de eventos de fin que indican las distintas categorías de los
resultados de los procesos. Un resultado es algo que ocurre al final de un camino particular
del proceso, por ejemplo un mensaje es enviado, una señal, entre otros. Todos los eventos de
fin lanzan un resultado. Cada uno de los tipos de evento de fin se diferencia con su propia
representación gráfica porque dentro del círculo del evento poseen un ícono el cual
representa: un mensaje, una señal, un terminal, una excepción, cancelar, entre otros.
Actividades
Una actividad representa una unidad de trabajo que es realizado o ejecutado dentro de
un proceso de negocio [38]. Una actividad generalmente lleva un tiempo para realizarla,
supondrá uno o varios recursos, suelen requerir algún tipo de entrada, y por lo general
producen algún tipo de salida. Las actividades representan puntos en un flujo de proceso en
donde se realizan trabajos. Estas actividades son elementos ejecutables en un proceso BPMN.
La Figura 2.6 muestra la representación gráfica de una actividad.
Figura 2.6: Actividad
Dentro de un proceso pueden existir tres tipos de actividades: tarea (tareas atómicas),
sub-proceso (no atómicas - tareas compuestas) y Call-Activity (subproceso reutilizable) [4].
Tareas
Una tarea se representa en un modelo de negocio con el mismo gráfico que una
actividad [38]. Una tarea se utiliza cuando el trabajo en el proceso no puede ser dividido en
mayor nivel de detalle. Una tarea representa una acción, no una función o estado.
Existen diferentes tipos de tareas identificadas en BPMN para separar los tipos de
comportamiento inherente que las tareas puedan representar. La Figura 2.7 muestra estos tipos
de tareas y ellas se diferencia gráficamente por un ícono en la esquina izquierda superior del
rectángulo. A continuación, se detallan estos tipos de tareas definidos en el estándar:
Abstracta (None): Tarea genérica o indefinida, se utiliza frecuentemente
durante las primeras etapas del desarrollo del proceso.
Usuario (User): Es un típico flujo de trabajo que lleva a cabo un humano con la
ayuda de una aplicación de software y que está programada a través de una
17
Abstracta Usuario Manual Envío
Recibo Servicio Script Regla de Negocios
lista de tareas.
Manual (Manual): Es una tarea que se espera llevar a cabo sin la ayuda de
ningún motor de ejecución de procesos de negocio o cualquier otra aplicación.
Un ejemplo podría ser un técnico de telefonía instalando un teléfono.
Envío (Send): Está diseñada para enviar un mensaje a un participante externo
(en relación al proceso). Una vez que el mensaje ha sido enviado, la tarea se ha
completado. Este tipo de mensaje es enviado a través de un flujo de mensaje.
Recepción (Receive): Está diseñada para esperar que llegue un mensaje de un
participante externo (en relación al proceso). Una vez que el mensaje ha sido
recibido, la tarea se ha completado. Este tipo de mensaje es recibido a través de
un flujo de mensaje.
Servicio (Service): Es una tarea que utiliza algún tipo de servicio, el cual puede
ser servicio web o una aplicación automatizada.
Script: Este tipo de tarea se ejecuta mediante un motor de procesos de negocio.
El modelador o implementador define el script en un lenguaje que el motor
puede interpretar. Cuando la tarea está lista para comenzar, el motor ejecutará
el script. Cuando el script es completado, la tarea finaliza.
Regla de Negocio: Son expresiones formuladas a través de reglas que serán
ejecutadas a través de un motor.
Figura 2.7: Tipos de Tareas
Sub-Procesos
Un sub-proceso representa una actividad la cual puede dividirse en un nivel de detalle
más fino. Un sub-proceso es un objeto gráfico dentro de un proceso, pero también puede ser
"expandido" para mostrar un proceso de nivel inferior. Existen dos representaciones gráficas
para los sub-procesos:
Colapsado: Los detalles del sub-proceso no son visibles en el diagrama. Su
representación se muestra en la Figura 2.8.
18
Call Activity llamando a Tarea de Usuario Global
Call Activity llamando a un Proceso (Colapsado)
Call Activity llamando a un Proceso (Expandido)
Figura 2.8: Sub-Proceso colapsado
Expandido: Este tipo de sub-proceso muestra los detalles del mismo, es decir
que los detalles son visibles dentro de los límites del sub-proceso (ver Figura
2.9).
Figura 2.9: Sub-Proceso expandido
Call Activity
Un Call Activity identifica un punto en el proceso donde otro proceso o una tarea
global son utilizadas. El Call Activity actúa como "envoltorio" para la invocación de un
proceso o tarea global dentro de la ejecución. En BPMN 2.0 un Call Activity corresponde a
sub-procesos reutilizables de BPMN 1.2. Un sub-proceso de BPMN 2.0 corresponde al sub-
proceso embebido de BPMN 1.2.
Un objeto Call Activity comparte la misma forma que las tareas y sub-proceso. Sin
embargo, su objetivo determinará los detalles de la forma. La Figura 2.10 muestra los tipos de
Call Activity que existen.
Figura 2.10: Tipos de Call Activity
19
Compuertas (Gateways)
Las compuertas son utilizadas para controlar los flujos de los procesos a través de los
flujos de secuencia que divergen o convergen dentro en un proceso [31]. Es decir, una única
compuerta puede tener múltiples entradas y múltiples flujos de salida. Para una mejor práctica
de las compuertas, las herramientas y los modeladores utilizan dos compuertas secuenciales
para converger primero y luego para divergir los flujos de secuencia. Si el flujo del proceso no
necesita ser controlado, las compuertas no son necesarias. El término "compuerta" implica
que existe un mecanismo de compuerta que permite o impide el paso a través de la misma.
Una compuerta divide el flujo cuando éste tiene múltiples flujos de secuencia salientes y
unificará el flujo cuando éste tiene múltiples flujos de secuencia entrantes [4].
Las compuertas no representan "trabajos a realizar" se considera que tienen un efecto
nulo sobre el funcionamiento del proceso en ejecución. Existen diferentes formas de controlar
un flujo de un proceso, para esto existen diferentes tipos de compuertas. Todos comparten la
misma forma básica, pero ellos se diferencian en los símbolos internos que poseen, los cuales
dependen de su comportamiento. Es decir, que dependiendo del tipo de decisión se puede
tener una compuerta particular. Entonces las compuertas se pueden dividir en múltiples tipos
como muestra la Figura 2.11.
Figura 2.11: Tipos de Compuertas
Una compuerta exclusiva divergente (decisión) es utilizada para crear caminos
alternativos dentro de un flujo de proceso. Esto es básicamente, el "punto de desvío en un
camino" para un proceso. Para una instancia de un proceso, sólo uno de los caminos puede ser
tomado. Un ejemplo de este tipo de compuerta puede verse en la Figura 2.12.
Figura 2.12: Compuerta Exclusiva divergente
Una compuerta exclusiva convergente se utiliza para unir caminos alternativos. Este
Exclusivo Inclusivo Paralelo Complejo Basado en eventos
Xo +
20
tipo de compuerta puede observarse en la Figura 2.13.
Figura 2.13: Compuerta Exclusiva convergente
Una compuerta inclusiva divergente (decisión incluida) se puede utilizar para crear
caminos alternativos o caminos paralelos dentro de un flujo de proceso. Su representación se
muestra en la Figura 2.14. A diferencia de la compuerta exclusiva, todas las expresiones de
condición son evaluadas. La evaluación de una condición a verdadera no excluye la
evaluación de las otras expresiones de condición. Puesto que cada camino se considera que es
independiente. Un camino por defecto puede ser tomado si ninguna condición evalúa en
verdadero. Si no se especifica un camino por defecto y ninguna de las expresiones evalúan a
verdadero se produce una excepción en tiempo de ejecución.
Figura 2.14: Compuerta Inclusiva divergente
Una compuerta inclusiva convergente se utiliza para unir una combinación de caminos
alternativos y paralelos de la misma manera que sucede con las compuertas exclusivas
convergentes.
Una compuerta paralela es utilizada para sincronizar o combinar flujos paralelos y
crear flujos paralelos. Cada camino saliente representa un hilo concurrente del proceso, es
decir que se solapan en tiempo de ejecución. Los caminos paralelos pueden unirse o
separarse. En éste último caso debe existir una compuerta paralela que una los caminos que
están ejecutándose paralelamente. La Figura 2.15 muestra este tipo de compuerta.
21
Figura 2.15: Compuerta Paralela
Las compuertas complejas se utilizan cuando se necesita manejar situaciones de
comportamientos complejos que las otras compuertas no pueden soportar. En la Figura 2.16
se puede observar dicha compuerta. Una expresión se utilizará para describir el
comportamiento exacto. Por ejemplo, esta expresión podría especificar que se necesitan tres
de cinco flujos de secuencia entrantes para activar la puerta de enlace. Las compuertas
complejas a diferencia de las otras compuertas, poseen un estado interno, el cual está
representado por un atributo de instancia booleano, que inicialmente es verdadero y se
convierte en falso después de la activación.
Figura 2.16: Compuerta Compleja
Una compuerta basada en eventos representa un punto de bifurcación en el proceso
donde los caminos alternativos que siguen a la compuerta se basan en eventos que se
producen, en lugar de la evaluación de las expresiones (al igual que las compuertas exclusivas
o inclusivas). Un evento específico, por lo general la recepción de un mensaje, determina el
camino que se tomará. Básicamente, la decisión es tomada por otro participante que no es
22
visible al proceso, por lo tanto, se requiere el uso de la compuerta basada en eventos. La
representación de este tipo de compuerta se puede observar en la Figura 2.17.
Figura 2.17: Compuerta Basada en Eventos
Datos
Uno de los cambios más significativos en la última versión del estándar BPMN
concierne al modelado de datos y flujo de datos. En la versión 1.2 los objetos de datos eran
considerados artefactos o anotaciones sin semántica ni reglas. En la última versión los objetos
de datos pasaron a ser un elemento de primer nivel con semántica. En esta nueva versión
también se incluyen los almacenes de datos (data stores). Estas nuevas definiciones permiten
construir diseños de procesos ejecutables [38]
Los datos están representados con cuatro elementos:
Objetos de Datos (Data Objects)
Almacén de Datos (Data Stores)
Datos de Entrada (Data Inputs)
Datos de Salida (Data Outputs)
Objetos de Datos
El constructor principal para el modelado de datos dentro del flujo de procesos es el
elemento objeto de datos. Un objeto de datos tiene un ciclo de vida bien definido. La Figura
2.18 muestra su representación gráfica.
Figura 2.18: Objeto de Datos
23
Los objetos de datos se muestran visualmente en el diagrama y deben estar contenidos
dentro de los elementos de un proceso o sub-proceso. Las referencias a objetos de datos son
una manera de reutilizar objetos de datos en el mismo diagrama. Con ellos se pueden
especificar diferentes estados de un mismo objeto de datos en diferentes puntos de un proceso.
Los objetos de datos actúan como entradas y salidas de las tareas. Un ejemplo de su
uso puede verse en la Figura 2.19
Figura 2.19: Ejemplo del uso de Objeto de Datos
Almacén de Datos
Un almacén de datos representa datos persistentes, tales como almacenamiento de
información en una base de datos, sistema de negocios, etc., pero no representa una base de
datos o un sistema en su totalidad [38]. Proporciona un mecanismo para que las actividades
puedan consultar o actualizar información almacenada que persistirá más allá del alcance del
proceso. Su notación puede verse en la Figura 2.20. El mismo almacén de datos se puede
visualizar a través de una referencia al almacén de datos, en uno o más lugares en el proceso.
Figura 2.20: Almacén de Datos
Datos de Entrada y Salida
Las actividades y los procesos necesitan frecuentemente datos en orden para poder ser
ejecutados. Además ellos pueden producir datos como resultados de la ejecución. Los
requerimientos de datos se capturan como datos de entrada. Los datos que son producidos por
la ejecución de las actividades y/o procesos se capturan mediante datos de salida. No todos los
tipos de actividades definen entradas y salidas, sólo las tareas, las tareas globales y los
procesos pueden definir los requerimientos de datos. Los sub-procesos embebidos no deben
definir datos de entrada y datos de salidas directamente, indirectamente podría hacerlo.
Orden
Almacén de
Datos
24
Datos de Entrada
Un dato de entrada es la declaración de un tipo particular de dato que será utilizado
como entrada para una actividad y/o un proceso. Puede haber múltiples datos de entrada.
Los datos de entrada se muestran visualmente en un diagrama de un proceso para
expresar las entradas del nivel superior del proceso o para mostrar las entradas a un proceso
llamado (es decir, una referencia a un Call Activity, donde el Call Activity ha sido expandido
para mostrar el proceso llamado dentro del proceso en el cual participa).
La representación de los datos de entrada se muestra en la Figura 2.21.
Figura 2.21: Dato de Entrada
Como se mencionó anteriormente, los datos de entrada son visibles en el nivel superior
del proceso, pero no pueden ser visualizados aquellos que posee una tarea.
Datos de Salida
Un dato de salida es la declaración de un tipo particular de dato que puede producir
una salida como resultado de una ejecución. Puede haber múltiples datos de salida.
Los datos de salida se muestran visualmente en un diagrama para expresar los
resultados del proceso.
La representación de los datos de salida puede observarse en la Figura 2.22.
Figura 2.22: Dato de Salida
De igual manera que los datos de entrada, los datos de salida son visibles en el nivel
superior del proceso, pero no pueden ser visualizados aquellos que posee una tarea.
Objetos de conexión
Los objetos de conexión son los encargados de conectar los elementos que pueden
aparecer en un proceso de negocio. Existen cuatro tipos de conectores:
Flujo de Secuencia (Sequence Flows)
Flujo de Mensajes (Message Flows)
Asociaciones (Associations)
Asociaciones de Datos (Data Associations)
25
Flujo de Secuencia
Un flujo de secuencia se utiliza para mostrar la secuencia en que las actividades son
ejecutadas en un proceso. Los flujos de secuencias poseen un origen y un destino. Ellos son
los encargados de conectar eventos, actividades y compuertas, siguiendo una serie de reglas o
restricciones, la Figura 2.23 muestra las posibles conexiones. Lo más importante es que los
flujos de secuencia no pueden cruzar los límites de un sub-proceso o de un proceso.
Figura 2.23: Reglas de Conexión para los Flujos de Secuencia
La Figura 2.24 muestra la representación de los flujos de secuencia.
Figura 2.24: Flujo de Secuencia
Un flujo de secuencia puede poseer una expresión de condición. Si la expresión evalúa
a verdadero el flujo continúa normalmente, si la expresión evalúa a falso el flujo no continúa.
Este tipo de flujos se utilizan cuando el origen del flujo de secuencia es una compuerta o una
actividad. La Figura 2.25 muestra su representación.
Desde/a
26
Figura 2.25: Flujo de Secuencia Condicional
Un flujo de secuencia que tiene una compuerta exclusiva, inclusiva o compleja o tiene
una actividad como fuente puede también ser definido como un flujo de secuencia por
defecto. Su representación se muestra en la Figura 2.26.
Figura 2.26: Flujo de Secuencia por Defecto
Las actividades pueden tener uno o más flujos de secuencia de entrada y uno o más
flujos de secuencia de salida. Todos los flujos de secuencia de entrada son totalmente
independientes entre ellos.
Los eventos de inicio sólo tienen flujos de secuencia de salida. Los eventos de fin
tienen una restricción similar pero opuesta para las conexiones, es decir que sólo tienen flujos
de secuencia de entrada.
Flujo de Mensajes
Un flujo de mensaje se utiliza para mostrar la secuencia de mensajes entre dos
participantes que están preparados para enviarlos y recibirlos. En BPMN, los participantes son
representados por pools.
Un flujo de mensajes debe conectar dos pools separados. No pueden conectar dos
objetos dentro del mismo pool ya que esto lo hacen los flujos de secuencia y los flujos de
datos. La Figura 2.27 muestra su representación.
Figura 2.27: Flujo de Mensaje
Las interacciones entre los pools son manejadas por los flujos de mensajes. Cuando el
pool se ve como una caja negra, el flujo de mensajes se conecta a su límite. Cuando un pool
tiene elementos del proceso, el flujo de mensajes se conecta a estos elementos.
Asociaciones
Una asociación es utilizada para asociar información y artefactos con elementos
gráficos BPMN, ya sean objetos de flujos o anotación de texto. Su representación gráfica se
muestra en la Figura 2.28.
27
Figura 2.28: Asociación
Las anotaciones de texto es un mecanismo para proporcionar información adicional
para el lector del modelo BPMN. El objeto de anotación de texto puede ser conectado a un
objeto específico con una asociación, pero éste no afectará al flujo del proceso. El texto se
coloca dentro de los límites de un rectángulo abierto (ver Figura 2.29).
Figura 2.29: Anotaciones de Texto
Asociaciones de Datos
Una asociación de datos es utilizada para mover datos entre objetos de datos,
propiedades, entrada/salidas de actividades, procesos y tareas globales. Una asociación de
datos tiene origen y destino; cuando la asociación de datos es ejecutada, el dato del origen de
la asociación es copiado en el destino.
Una asociación de datos puede representarse visualmente como una línea punteada
generalmente con dirección. La Figura 2.30 muestra un ejemplo de las asociaciones de datos.
Figura 2.30: Asociación de Datos
Las asociaciones de datos son utilizadas en las diferentes etapas del proceso y en el
ciclo de vida de una actividad, entonces sus posibles fuentes pueden variar dependiendo de la
etapa en la cual se encuentre.
Una asociación de datos dirigida hacia un almacén de datos representa una
actualización sobre el almacén, mientras que una asociación de datos que sale de un almacén
representa una consulta sobre el mismo [38].
Un ejemplo de la utilización de las asociaciones de datos puede verse en la Figura
Orden
28
2.31, en ella se observan asociaciones de datos hacia y desde un objeto de datos, y una
asociación de datos hacia un almacén.
Figura 2.31: Ejemplo de utilización de las Asociaciones de Datos
Carriles (Swimlanes)
Para dividir y organizar actividades en un diagrama, BPMN utiliza los carriles.
Existen dos maneras de agrupar los elementos primarios que pueden aparecer en un proceso
de negocio:
Pools
Carril (Lanes)
Pool
Un pool representa un participante en un proceso. Un pool contiene elementos de flujo
básicos (eventos, actividades y compuertas). Además actúa como un contenedor gráfico para
particionar un conjunto de actividades de otros pools, como sucede en un contexto Negocio-a-
Negocio (Business to Business - B2B). Como se mencionó anteriormente, los pools pueden
ser vistos como una “caja negra” o una “caja blanca”. Si se ve como una “caja negra”
significa que no se requiere contener a un proceso. Si se observa como una “caja blanca”
significa que se pueden ver los elementos de flujos dentro del pool. La Figura 2.32 muestra la
representación gráfica de un pool.
Figura 2.32: Pool
Como se observa en la Figura 2.32, el pool puede poseer una etiqueta (Nombre), pero
debe estar separada de los contenidos del pool por una línea. Generalmente esta etiqueta
representa el nombre del proceso.
Orden
Cuenta
Cliente
Nom
bre
29
Uno solo pool puede presentarse sin límites, pero si existe más de un pool en el
diagrama éstos deben tener límites (ver Figura 2.33).
Figura 2.33: Ejemplo de un proceso con más de un Pool
Los flujos de secuencia pueden cruzar los límites entre los carriles de un pool, pero no
pueden cruzar los límites de un pool, ya que esto se realiza a través de los flujos de mensajes,
como se mencionó anteriormente.
Carril
Un carril representa una sub-división dentro de un pool. Un carril se representa de la
misma manera que el pool. También posee una etiqueta pero ésta no debe estar separada por
una línea de los contenidos del carril (excepto en los casos el caso de que existan sub-
Carriles). La Figura 2.34 muestra su representación gráfica.
Figura 2.34: Dos Carriles en un Pool
Los carriles se utilizan para organizar y categorizar actividades dentro de un pool, pero
su significado es exclusivamente para el modelador. Los carriles se pueden anidar. Un
ejemplo de esto sería modelar un conjunto exterior de carriles para los departamentos de una
empresa y un conjunto interior de los carriles para los roles dentro de cada departamento.
BPMN no especifica la utilización de los carriles. Ellos se utilizan generalmente para
mostrar roles internos, como por ejemplo gerentes, vendedores, clientes, etc., o para mostrar
Pa
cie
nte
Recibir
requerimiento Enviar
respuesta
Recibir
Síntomas
Enviar
prescripción
Nom
bre
Nom
bre
Nom
bre
30
sistemas, departamentos internos a una empresa, por ejemplo el departamento de finanzas,
etc.
Artefactos
Un artefacto es utilizado para proveer información adicional a un proceso. Existen dos
tipos de artefactos estandarizados, pero en las herramientas de modelado se pueden encontrar
más. Los artefactos incluidos en el estándar son:
Grupo (Group)
Anotación de Texto (Text Annotation)
Grupo
Un grupo es un mecanismo visual para agrupar informalmente elementos en un
diagrama. Su representación se puede observar en la Figura 2.35.
Figura 2.35: Un Grupo
Los grupos no pueden ser conectados a través de flujos de secuencia o flujos de
mensajes porque no son actividades u objetos de flujo, son artefactos. Es decir, un grupo no
posee las restricciones de los pools y de los carriles, esto quiere decir que los grupos pueden
extenderse a través de los límites de un pool. Frecuentemente se utilizan para identificar las
actividades que existen dentro de una transacción B2B.
Anotación de Texto
Como se mencionó anteriormente, una anotación de texto es un mecanismo para
proporcionar información adicional para el lector del modelo BPMN, ya que no afectará al
flujo del proceso. El texto se coloca dentro de los límites de un rectángulo abierto. Su
representación se puede observar en la Figura 2.36.
Figura 2.36: Un Anotación de Texto como Artefacto
La Anotación de Textoprovee información adicional
31
2.6 Flujos de Trabajo (Workflows)
La Coalición de Gestión Workflow (Workflow Management Coalition – WfMC), unas de
principales organizaciones que desarrolla y promociona estándares en el campo de flujo de
trabajo, define flujo de trabajo como: “la facilitación computarizada o la automatización de
procesos de negocio, en su totalidad o en parte.”[39]
Un flujo de trabajo es considerado como un conjunto de uno o más procedimientos o
actividades relacionadas, que en conjunto se realizan para lograr un objetivo de negocio,
generalmente dentro del contexto de una organización la cual define roles funcionales y
relaciones entre ellos [39].
Un sistema de gestión de flujo de trabajo proporciona la automatización de los
procedimientos de un proceso de negocio. Hollingsworth en [39] define el Sistema de Gestión
de Flujo de Trabajo (SGFT) como: “Un sistema que define completamente, gestiona y ejecuta
"workflows" a través de la ejecución de software cuya orden de ejecución está dada por una
representación informática de la lógica del workflow.”
Los flujos de trabajo tienen como misión apoyar procesos estructurados orientados a la
administración, en los cuales intervienen varios actores. Los beneficios no sólo son respecto al
ahorro de tiempo en el manejo de papeles, sino que también los flujos de trabajo permiten:
conectar las actividades y aplicaciones que pertenecen a un mismo proceso,
apoyar la coordinación de las personas,
dar seguimiento a las tareas,
evaluar la efectividad en el cumplimiento de los compromisos,
reconfigurar procesos sin tocar los sistemas.
2.6.1 Sistemas de Gestión de Flujos de Trabajo
Los SGFT pueden ser implementados de diferentes maneras como resultado de la utilización
de diferentes plataformas y tecnologías. Pueden ir desde un pequeño grupo de trabajo a una
gran organización. No obstante, todos los SGFT muestran ciertas características comunes. Al
más alto nivel, todos los SGFT se pueden caracterizar como la prestación de soporte en tres
áreas funcionales [39]:
Las funciones en tiempo de diseño, dedicadas para definir y modelar procesos
de flujos de trabajo con todas sus actividades.
Las funciones de control en tiempo de ejecución, relacionados con la gestión
de los procesos que controlan el entorno operativo y ejecutando las diversas
actividades que se manejan como parte de cada proceso.
Las interacciones en tiempo de ejecución con los usuarios humanos y
herramientas informáticas para el procesamiento de los distintos pasos de la
actividad.
32
Las características básicas de los SGFT y las relaciones entre estas funciones
principales pueden verse en la Figura 2.37.
Figura 2.37: Características de los SGFT [39]
2.6.2 Estándares para modelado de flujos de trabajo
Para poder modelar los flujos de trabajo es necesario un lenguaje o una herramienta de
modelado. Estos lenguajes o herramientas pueden ser clasificados como formales y no
formales. Además en esta clasificación se puede observar aquellas que poseen un ambiente
gráfico para el modelado y las que no.
Las herramientas de modelado formales, se basan en matemática y permiten que un
modelo pueda ser analizado y verificado. De esta manera, logran asegurar el mayor grado de
ausencia de errores. La desventaja que poseen es que requieren más conocimiento por parte
del modelador. Algunos ejemplos de éstas son: redes de Petri y máquinas de estados.
Las herramientas informales permiten construir modelos fáciles de comprender, sin
embargo, no es posible verificarlos, lo cual implica que se debe tener el sistema desarrollado e
implementado para poder verificar que todos sus módulos funcionen correctamente. Algunos
ejemplos de estas herramientas son: UML, BPMN, Diagramas IDEF, modeFRONTIER, entre
otros.
Por otra parte, un proceso de flujo de trabajo puede ser modelado desde distintas vistas
o perspectivas. Cada vista representa algo que se considera importante para un proceso. Se
puede considerar las siguientes perspectivas [40]:
Perspectiva de flujo de control (o de procesos), la cual describe las actividades
y su ejecución.
Perspectiva de datos, la cual delimita y describe el procesamiento de datos
33
sobre la perspectiva de control.
Perspectiva de recursos, la cual provee la estructura organizacional (personas y
dispositivos que poseen un rol responsable en las actividades).
Perspectiva operacional, la cual describe las acciones elementales ejecutadas a
través de actividades donde las acciones son mapeadas desde aplicaciones.
La WfMC fue la pionera en dar los primeros pasos para desarrollar y promover los
SGFT. Estableciendo estándares se promovería el uso de SGFT ya que facilitarían la creación,
desarrollo y análisis de los sistemas. La WfMC definió una serie de estándares entre los que
se destaca el Modelo de Referencia [39]. Este modelo describe la arquitectura básica de un
SGFT.
2.6.3 Flujos de Trabajo Científicos
Un flujo de trabajo científico o ingenieril es un proceso de negocio automatizado. Este tipo de
flujo es generalmente utilizado para ejecutar tareas de procesamiento computacional
complejas en áreas de aplicaciones científicas o ingenieriles. Además, es ampliamente
utilizado en ciencias naturales, simulaciones computacionales, química, medicina, ciencias
ambientales, ingeniería, geología, astronomía, industria automotriz y aeroespacial, entre otros
campos [34]. También se puede considerar a los flujos de trabajo científicos como secuencias
de pasos analíticos que pueden implicar, por ejemplo, acceso y consultas a base de datos,
análisis de datos relacionados a la minería, incluyendo trabajos computacionalmente
intensivos en equipos de clúster de alto rendimiento [41].
El paradigma de flujos de trabajo para aplicaciones científicas como Grids2 puede
ofrecer muchas ventajas tales como [42]:
Capacidad de crear aplicaciones dinámicas que orquestan recursos distribuidos.
Utilización de los recursos, que se encuentran en un dominio particular, para
incrementar el rendimiento y reducir los costos de ejecución.
Integración de múltiples equipos que participan en la gestión de las diferentes
partes del flujo de trabajo, promoviendo así la colaboración entre
organizaciones.
Los flujos de trabajo científicos se están convirtiendo en un mecanismo importante
para los científicos para combinar la gestión científica de datos, análisis, simulación y tareas
de visualización. Las características y requerimientos de los flujos de trabajo científicos
suelen superponerse a los flujos de trabajo de negocios. Pero existen diferencias entre ellas,
algunas diferencias son significativas [43]:
Los flujos de trabajo de negocio operan con datos que generalmente están
2 Federación de los recursos informáticos distribuidos para alcanzar un objetivo común. Puede ser pensado como
un sistema distribuido con cargas de trabajo no interactivos que involucran a un gran número de archivos
34
almacenados en bases de datos. Por el contario, los flujos de trabajo científicos
operan con grandes cantidades de datos, complejos y heterogéneos. Estos datos
son generalmente almacenados en grandes archivos y codificados en distintos
formatos, dependiendo del campo científico que se esté modelando.
Los flujos de trabajo científicos pueden ser computacionalmente intensivos y
pueden producir datos complejos que pueden ser reutilizados por otros flujos
de trabajo.
Los flujos de trabajo de negocio y su ejecución están enfocados en los flujos de
control y los eventos, mientras que los flujos de trabajo científicos tienden a
tener modelos de ejecución con mucho manejo de datos.
2.6.4 Modelo de referencia de flujos de trabajo
El Modelo de Referencia de Flujo de Trabajo que propuso la WfMC se desarrolló partiendo
de una estructura de aplicación de flujo de trabajo genérica, a través de la identificación de
interfaces dentro de la estructura, las cuales permiten que los productos puedan interoperar en
diferentes niveles. Los sistemas de flujos de trabajo contienen componentes genéricos que
pueden interactuar y los productos están contenidos en estos componentes [39].
Como se dijo anteriormente, para lograr la interoperabilidad entre los productos de
flujos de trabajo, es necesario un conjunto estandarizado de interfaces y formatos para el
intercambio de datos entre los componentes.
Por otro lado, uno de los objetivos de la WfMC fue definir estándares para el
desarrollo de SGFT, para esto brinda un marco general para la construcción de los mismos.
El modelo de referencia identifica áreas funcionales distintas para luego desarrollar las
especificaciones para la implementación de estas áreas. De esta manera asegura la
interoperabilidad entre los distintos SGFT y la integración con otras aplicaciones
informáticas. El modelo de referencia de flujos de trabajo se muestra en la Figura 2.38.
Figura 2.38: Modelo de Referencia: Componentes e Interfaces [39]
35
En la Figura 2.38 pueden observarse las principales componentes y las interfaces. El
detalle de las interfaces, como las APIs y los formatos de intercambio, si es posible, son
desarrolladas como un conjunto básico común. Cuando haya requerimientos particulares de
las interfaces, es necesaria la presencia de parámetros adicionales. Las APIs y los formatos de
intercambio se pueden considerar como un conjunto de constructores a través de cuales los
servicios del sistema de flujo de trabajo pueden ser accedidos. Estos constructores pueden
regular la interacción entre el software de control de flujos de trabajo y otros componentes del
sistema.
El componente central es el Servicio de Ejecución de Flujo de Trabajo. Éste es el
encargado de crear, gestionar y ejecutar cada una de las instancias del modelo del flujo de
trabajo. En este componente se encuentra el motor del SGFT que proporciona la ejecución de
cada instancia de flujo de trabajo. Este servicio de software puede consistir de uno o más
motores de flujos de trabajo. Un motor de flujo de trabajo es el responsable de parte o todo el
ambiente de control de ejecución dentro del servicio. Un motor de flujo de trabajo puede
controlar la ejecución de un conjunto de procesos, sub-procesos o instancias con un alcance
definido, determinado por los tipos de objetos y sus atributos.
Otro de los componentes es el de Herramientas de Definición del Proceso. Estas
componentes permiten modelar, describir y documentar un determinado flujo de trabajo o un
proceso de negocio. Las herramientas aquí pueden ser totalmente informales, como lenguaje
natural (en papel y lápiz), o formalizadas como interfaces gráficas con un modelo subyacente
bien definido. Permiten especificar la lógica del proceso, las actividades que lo componen, los
participantes humanos, datos utilizados, entre otros.
La interfaz 1 permite la comunicación entre este componente y el servicio de ejecución
de flujo de trabajo. Además es la encargada del intercambio de información entre el
componente que permite la definición del proceso y el propio servicio de ejecución de flujo de
trabajo. Esta interfaz hace necesaria la definición de un metamodelo básico, que identifique el
conjunto básico de entidades para la definición de un proceso, permitiendo el intercambio de
información entre ambos componentes. Es posible añadir más tipos de objetos, ya sea a través
de extensiones específicas o mediante la definición de niveles adicionales con mayor
funcionalidad.
El componente denominado Aplicaciones Cliente del Flujo de Trabajo representa las
entidades de software utilizadas por el usuario final. Es decir representan aquellas actividades
que requieren participación humana para su realización. La interfaz 2 puede ser necesaria para
definir y manejar los conceptos de listas de trabajo, en el caso de que este componente se
separe de lo que es propio de la ejecución. Esta interfaz debe ser lo suficientemente flexible
para: identificar procesos y actividades, referencias a datos y estructuras de datos,
mecanismos de comunicación alternativos, entre otros.
36
El componente Aplicaciones Invocadas representa software o aplicaciones existentes
que un SGFT puede utilizar. Estas aplicaciones pueden encontrarse en cualquier plataforma o
lugar de la red. La interfaz 3 permite la comunicación entre este componente y el servicio de
ejecución de flujo de trabajo. Esta comunicación puede ser a nivel de invocación y a nivel de
transformación de datos en formatos entendibles por ambos componentes.
El componente Otros Servicios de Ejecución de Flujo de Trabajo es utilizado para la
interoperabilidad entre SGFT. La interfaz 4 es la que permite esta comunicación. Existen dos
aspectos importantes para la interoperabilidad: el alcance para el cual la interpretación común
de la definición de proceso es necesaria y puede ser lograda, y el soporte de tiempo de
ejecución para el intercambio de diversos tipos de información de control, además de
transferir los flujos de trabajo relevantes y/o aplicaciones de datos entre los diferentes
servicios.
El componente Herramientas de Administración y Monitorización permite que
distintos servicios de ejecución de flujo de trabajo compartan las mismas funciones de
administración y monitorización del sistema, como por ejemplo la gestión de usuarios, el
control de los recursos, entre otros. La interfaz 5 es capaz de manejar varias funciones
adicionales (heterogénea) a través dominios de flujos de trabajo. También es factible para la
aplicación de gestión tomar otras funciones de gestión. Por ejemplo, también se puede
gestionar las definiciones de proceso de flujos de trabajo, actuando como un repositorio y
distribución de definiciones de procesos a los distintos dominios de flujos de trabajo.
37
Capítulo 3
Arquitectura Dirigidas por Modelos
El presente capítulo resume los principales conceptos relacionados a la Ingeniería Dirigida
por Modelos (MDE) y a la propuesta Arquitectura Dirigida por Modelos (MDA), visión de
MDE en la OMG. Inicialmente se realiza una reseña sobre el paradigma MDE. Luego se pone
énfasis en la propuesta MDA, creada por la OMG como implementación de MDE. Además se
provee la definición de MDA y los principios que la sustentan, así como los tipos de modelos
que la comprenden. También se introduce la transformación de modelos como proceso clave
de MDA y de este trabajo de tesis, conjuntamente con los estándares involucrados en MDA
poniendo mayor énfasis en el lenguaje de transformación de modelos QVT. En particular se
muestra y explica la construcción de una transformación en el lenguaje QVT-Relations a
través de un ejemplo.
3.1 Introducción
Ingeniería Dirigida por Modelos (Model Driven Engineering – MDE) tiene como objetivo
elevar el nivel de abstracción en la especificación de programas e incrementar la
automatización en el desarrollo de los mismos. MDE impulsa el uso de modelos como
artefactos3 principales a ser construidos y mantenidos. El término MDE fue propuesto por
Stuart Kent, quien lo define como la combinación de procesos y análisis en conjunto con la
arquitectura [56]. Cualquier especificación puede ser expresada con modelos, en consecuencia
un proceso de desarrollo de software se convierte en un proceso de refinamiento y
transformación entre modelos de manera tal que el nivel de abstracción vaya decrementando
hasta llegar al código para una plataforma específica.
Un modelo es una representación abstracta de una realidad (sistema). Un modelo está
constituido por un conjunto de elementos que proporcionan una descripción sintética y
3 Artefacto: información que es utilizada o producida por un proceso de desarrollo de software. Pueden ser
modelos, descripciones hasta un sistema.
38
abstracta de un sistema. Éste permite estudiar un sistema y comprenderlo mejor. Los modelos
pueden construirse en distintos niveles de abstracción, para en un paso posterior, generar el
código correspondiente.
El incremento de la automatización en el desarrollo de programas puede ser alcanzado
utilizando transformaciones ejecutables de modelos. Los modelos de alto nivel pueden ser
refinados y transformados en modelos de más bajo nivel, permitiendo la ejecución del mismo.
Arquitectura Dirigida por Modelos (Model Driven Architecture - MDA) [6] [7] y
MDE [8] [9] proponen un proceso de desarrollo de software en el cual la clave son los
modelos y las transformaciones entre modelos. En este proceso, el software es desarrollado
construyendo uno o más modelos, y transformando estos en otros modelos. A su vez, estos
modelos pueden ser transformados hasta llegar a código ejecutable.
La transformación de modelos es el objetivo de MDE teniendo como premisa que los
modelos son entidades productivas. La iniciativa de MDE cubre varias áreas de investigación:
lenguajes de modelado, definición de lenguajes para transformación de modelos, construcción
de herramientas, etc. Actualmente algunos de estos aspectos están bien estudiados y otros
están en un proceso de definición. En este contexto, es necesario convertir MDE y sus
conceptos en una propuesta coherente, basado en estándares abiertos, con técnicas y el soporte
de herramientas maduras.
La definición de transformaciones de modelos requiere la aplicación de lenguajes
específicos. Estos lenguajes deberían tener una base formal, y al menos un metamodelo
describiendo su sintaxis abstracta [46]. La transformación de modelos se refiere al proceso de
transformación (relaciones y mapeo) de elementos de un modelo a elementos
correspondientes de otro modelo. Estas transformaciones son usualmente definidas en el nivel
de metamodelo M2 de la OMG [47]4 y aplicado al modelo de nivel M1 del mismo.
Los modelos son especificados en alguna notación o lenguaje de modelado. Como se
mencionó anteriormente, la sintaxis de un lenguaje se define mediante un metamodelo. La
semántica también puede, en algunos casos, definirse por un metamodelo, pero en la mayoría
de los casos prácticos la semántica no se define explícitamente, sino que es derivado del
comportamiento en tiempo de ejecución.
Por otra parte, la calidad en el desarrollo de software es un aspecto importante en
MDE. La calidad con MDE puede ser comprobada o asegurada con tres técnicas diferentes:
validación de modelos, verificación de modelos y pruebas basadas en modelos.
La verificación de modelos se refiere a la construcción correcta de un modelo.
Se puede definir en términos más simples diciendo que la verificación consiste 4 UML 2.1.2 Infraestructure, pag 19.
39
en determinar si existen errores en el modelo.
La validación se refiere a la construcción de un modelo correcto. La validación
es el proceso de determinar si el modelo, como abstracción, es una buena
representación del sistema.
La idea de las pruebas basadas en modelos ha permanecido por décadas. Moore [44]
inició la investigación con la generación de pruebas basadas en máquinas de estados finitos en
el año 1956.
Las pruebas basadas en modelos son definidas como las pruebas de software
donde los casos de pruebas son derivados en todo o en parte de un modelo que
describe algunos, si no todos, aspectos del sistema bajo prueba [45].
Como se mencionó anteriormente, MDE busca incrementar la productividad, mejorar
la calidad, y reducir los costos del proceso de desarrollo de software. Persiguiendo este
objetivo ha crecido el interés en este campo. Prueba de ello es la aproximación a la
Arquitectura Dirigida por Modelos [6], apoyada por el OMG.
MDA es la visión de MDE en la OMG. MDA es un marco de trabajo para el desarrollo
de software definido por la OMG. La clave de MDA está en la importancia de los modelos en
el proceso de desarrollo de software. Con MDA el proceso de desarrollo de software está
dirigido por la actividad de modelar el sistema de software [7].
3.2 MDA
En el 2001 la OMG adopta el marco de trabajo para la implementación de sistemas
distribuidos MDA, el cual provee un enfoque para la utilización de modelos en el desarrollo
de software. MDA proporciona un enfoque abierto e independiente del proveedor ante el
desafío de los posibles cambios en la tecnología y/o negocio.
La Figura 3.1 muestra la arquitectura de MDA. En el centro de la figura se encuentran
los estándares, para el modelado, de la OMG: UML, MOF y CWM (Common Warehouse
MetaModel). En base a estos estándares se construyen los modelos centrales de las
aplicaciones. Estos modelos deben ser independientes de cualquier plataforma y representan
características comunes a todas las plataformas en su categoría. El anillo que continua hacia
afuera del modelo MDA muestra plataformas específicas. Estas plataformas también se
modelan utilizando perfiles UML. Como se observa en la Figura 3.1 se puede tener perfiles
para plataformas como: CORBA, XMI/XML, .NET, Java, Web Services, etc. Definida la
funcionalidad y el comportamiento de la aplicación a través de un modelo independiente de la
plataforma se debe transformar a un modelo con una plataforma específica. Luego se genera
el código de la aplicación. Mientras más preciso sea el modelo más completo es el código que
se genera. Luego pueden observarse los servicios extendidos en el anillo que le sigue. Estos
40
servicios esenciales están disponibles para cualquier aplicación de Internet o Incrustada, e
incluyen: Directorios, Eventos, Persistencia, Transacciones y Seguridad. Finalmente se
muestran las áreas que abarca MDA [53].
Figura 3.1: Arquitectura Dirigida por Modelos de la OMG [49]
Basado en los estándares de la OMG, MDA separa la lógica de negocio y aplicación
de la plataforma subyacente. Los PIMs de una aplicación o el funcionamiento de sistemas de
negocios integrados construidos con UML y otros estándares para el modelado de la OMG,
pueden ser realizados a través de MDA en cualquier plataforma, abierta o propietaria,
incluyendo servicios Web, CORBA, J2EE entre otros. Estos modelos independientes de la
plataforma tienen la cualidad de que los modelos son independientes de las características de
cualquier tipo de plataforma tecnológica, además documentan la funcionalidad y
comportamiento de una aplicación separada de la tecnología específica [49].
El ciclo de vida de desarrollo de MDA es similar a los tradicionales, los artefactos son
creados durante el desarrollo del proceso y en su mayoría son modelos. MDA comienza con
la idea bien conocida y establecida de separar la especificación de la operación de un sistema
a partir de los detalles del sistema y su plataforma. Además MDA proporciona un enfoque
para:
especificar sistemas independientemente de la plataforma,
especificar plataformas,
elegir una plataforma particular para el sistema, y
transformar la especificación del sistema en una plataforma particular.
41
MDA posee como base cuatro principios [52]:
1) Los modelos expresados en una notación bien definida son la piedra angular para
comprender sistemas altamente escalables.
2) La construcción de sistemas puede ser organizada en torno a un conjunto de modelos
mediante la imposición de una serie de transformaciones entre modelos, organizados
en un marco de trabajo arquitectónico en capas y transformaciones.
3) Un conjunto de metamodelos es el respaldo para describir modelos. Éste facilita la
integración y transformación entre modelos y es la base para la automatización a
través de herramientas.
4) La aceptación y adopción generalizada de este enfoque basado en modelos requiere
estándares industriales para proveer transparencia a los usuarios.
Para sostener los principios antes mencionados, la OMG ha definido un conjunto
específico de capas y transformaciones que proveen un marco conceptual y un vocabulario
para MDA. En particular, la OMG identifica tres tipos de modelos los cuales cubren todo el
ciclo de vida de un sistema de software: Modelo Independiente de la Computación
(Computation Independent Model - CIM), Modelo Independiente de la Plataforma (Platform
Independent Model - PIM) y Modelo Específico de la Plataforma (Platform Specific Model -
PSM).
Modelo Independiente de la Computación (CIM)
Un modelo independiente de la computación es una perspectiva de un sistema desde el punto
de vista de computación independiente. Un CIM no muestra detalles de la estructura de los
sistemas y a veces es llamado modelo de dominio o modelo de negocio, además un
vocabulario familiar para los practicantes es utilizado en su especificación. CIM juega un rol
importante en la reducción de la línea entre los que son expertos acerca del dominio y sus
requisitos y los que son expertos en el diseño y construcción de los artefactos.
Los requerimientos para el sistema se modelan en un CIM y este representa el nivel
más alto del modelado. Se puede ocultar mucho o toda la información sobre el uso de los
sistemas automatizados de procesamiento de datos. Típicamente, dicho modelo es
independiente de cómo se implemente el sistema.
CIM es un modelo de un sistema que es visualizado a través del entorno en el cual va a
operar, esto ayuda a comprender exactamente que se espera que haga el sistema. Esto es útil,
no sólo porque ayuda al entendimiento del problema, sino que también se utiliza como fuente
de un vocabulario compartido para usar en otros modelos. Una especificación MDA de un
sistema de requerimientos CIM debe ser trazable para las construcciones de PIM y PSM que
los implementan [6].
42
Un objetivo fundamental de CIM es que cualquiera que sea capaz de comprender las
necesidades y los procesos que actuarán pueda comprender un CIM, ya que este modelo se
desliga de todo tipo de conocimiento de sistemas.
Modelo Independiente de la Plataforma (PIM)
Un modelo independiente de la plataforma es una vista de un sistema el cual representa su
lógica y sus interacciones con el mundo exterior, ocultando los detalles necesarios para una
plataforma en particular, además no muestra los detalles del uso de su plataforma [50]. Una
vista independiente de la plataforma muestra parte de la especificación completa que no
cambia de una plataforma a otra.
Un PIM representa un modelo sin hacer referencia a ninguna plataforma en la cual
será desarrollada la aplicación, además ignora los sistemas operativos, los lenguajes de
programación, el hardware, etc. Es decir que este modelo debe tener tal nivel de abstracción
que no cambie, sea cual fuere la plataforma elegida para su implementación.
Una técnica muy común para lograr la independencia de plataformas es apuntar a un
modelo de sistema de una máquina virtual de tecnología neutra. Una máquina virtual se define
como un conjunto de partes y servicios (comunicaciones, programación, nombres, etc.) los
cuales son definidos independientemente de cualquier plataforma específica pero que son
realizados pensando en plataformas específicas. Este tipo de modelo es independiente de la
plataforma ya que ellos no se ven afectados por la plataforma subyacente [6].
Modelo Específico de la Plataforma (PSM)
Un modelo específico de la plataforma es una perspectiva de un sistema desde el punto de
vista específico de la plataforma, es decir un PSM es un modelo del sistema con detalles
específicos a la plataforma en la cual será implementado. Como consecuencia, los PSMs
tienen que tener en cuenta explícitamente los sistemas operativos, los lenguajes de
programación y las plataformas entre otros. Un PSM producido por la transformación desde
un PIM, representa el mismo modelo pero desde otro nivel de abstracción.
PSM puede proveer más o menos detalles, dependiendo de su propósito. PSM será una
implementación, si éste proporciona toda la información necesaria para construir un sistema y
ponerlo en funcionamiento, o puede actuar como un PIM que es utilizado para promover el
refinamiento para un PSM que puede ser directamente implementado [6].
Se puede decir entonces que un PSM es un PIM el cual tendrá detalles específicos para
ser implementado en una plataforma determinada. PSM es un modelo de bajo nivel, muy
cercano al código. Se pueden generar varios PSMs para un mismo PIM, ya que cada uno
puede mostrar diferentes vistas [51] (ver Figura 3.2).
43
Por ejemplo, en una base de datos relacional un PSM incluye términos como: „tabla‟,
„columna‟, „clave‟, etc.
Figura 3.2: Transformación de modelos
3.3 Beneficios de MDA
La principal ventaja de MDA reside en una clara y estricta separación de responsabilidades.
Por un lado, se modelan los PIMs los cuales representan los modelos del sistema a construir, y
por el otro, los PSMs con las cuestiones tecnológicas. Esto permitirá que ambos modelos
evolucionen por separado. De esta manera, si se quiere, por ejemplo, modificar un aspecto
técnico, bastaría con modificar el PSM sin que éste tuviera impacto sobre el PIM.
Los objetivos principales de MDA son [7]:
Productividad:
En MDA el foco del desarrollo está puesto sobre los PIMs. Los PSMs se generan
automáticamente a partir del PIM. Lógicamente, alguien tiene que definir las
transformaciones exactas, lo cual es una tarea especializada y difícil. Pero una vez
implementada la transformación, puede usarse en muchos desarrollos. La mayoría de
los desarrolladores están focalizados en el desarrollo de los PIMs y ellos pueden
trabajar independientemente de los detalles y especificaciones de las plataformas. Los
detalles técnicos deberían ser automáticamente agregados en la transformación entre
PIM y PSM. Lo mismo sucede con la generación de código a partir de los PSMs.
Este enfoque centrado en el PIM aísla los problemas específicos de cada plataforma y
se ajusta mucho mejor a las necesidades de los usuarios finales, puesto que se puede
añadir funcionalidad con menos esfuerzo. De esta manera el trabajo duro recae sobre
las herramientas de transformación y no sobre el desarrollador.
Portabilidad:
En MDA, la portabilidad se logra también enfocando el desarrollo sobre el PIM. Al ser
un modelo independiente de cualquier tecnología, todo lo definido en él es totalmente
CIM PIM
PSM 1
PSM 2
PSM n
44
portable. El mismo PIM puede ser automáticamente transformado en múltiples PSMs
para diferentes plataformas. La portabilidad puede lograrse dependiendo de las
herramientas de transformación que estén disponibles. Para las plataformas populares
existe un gran número de herramientas disponibles, no así para las plataformas menos
conocidas. De todas maneras, otra vez el peso recae sobre las herramientas de
transformación que realizan automáticamente el paso del PIM al PSM de la plataforma
deseada.
Interoperabilidad:
Los PSMs generados a partir de un PIM normalmente tienen relaciones, que es lo que
MDA llama puentes (bridge). Normalmente los distintos PSMs no pueden
comunicarse con ellos directamente, ya que pueden pertenecer a distintas tecnologías.
Este problema lo soluciona MDA generando no sólo los PSMs sino también los
puentes entre ellos.
Como es razonable, estos puentes serán construidos por las herramientas de
transformación, que como se ha visto son uno de los pilares fundamentales en MDA.
Si la transformación a partir de un PIM genera más de un PSM con distintas
plataformas, es necesario un puente que vincule estos PSM, ya que cada elemento de
un PSM tiene una correspondencia con otro elemento del otro PSM generado.
Mantenimiento y Documentación:
Como ya se ha dicho, los desarrolladores se focalizan en la construcción del PIM y a
partir de éste se generan los PSMs, y luego el código. Básicamente, el PIM desempeña
el papel de la documentación de alto nivel que se necesita para cualquier sistema
software. El modelo es una representación exacta del código. La gran diferencia es que
el PIM no se abandona tras la codificación ya que los cambios realizados en el sistema
se deben reflejar en todos los niveles cambiando el PIM, regenerando los PSMs y el
código. Aun así, se sigue necesitando documentación adicional que no puede
expresarse con el PIM, por ejemplo, argumentar las elecciones de realizadas en el
desarrollo del PIM.
3.4 Transformación de Modelos y Metamodelos
El concepto de transformación de modelos es clave en la Ingeniería Dirigida por Modelos.
Como se mencionó en la sección de introducción, las transformaciones son usualmente
definidas en el nivel de metamodelo M2 de la OMG [47] y son aplicadas al modelo de nivel
M1 del mismo. Una transformación de modelos toma como entrada un modelo acorde a un
determinado metamodelo y produce como salida otro modelo acorde también a un
45
determinado metamodelo. Más precisamente, y de acuerdo con la definición que da Kleppe et
al [7]: “Una transformación es la generación automática de un modelo destino a partir de un
modelo origen de acuerdo a una definición de transformación”.
Un metamodelo define el lenguaje con el cual se construyen modelos. Un metamodelo
describe el conjunto de modelos admisibles y define formalmente los elementos de un
lenguaje de modelado junto con sus relaciones y restricciones.
Existen diferentes lenguajes para definir metamodelos. UML, por ejemplo, es un
metamodelo que especifica cómo crear modelos UML. Es decir, un modelo UML es una
instancia del metamodelo UML.
La transformación de modelos es un proceso el cual convierte un modelo en otro
representando el mismo sistema y ocurre en tiempo de ejecución. Una transformación puede
realizarse de manera horizontal o vertical. En una transformación horizontal el modelo fuente
se encuentra en el mismo nivel de abstracción que el modelo destino, por ejemplo, cuando se
realiza refactorización. En una transformación vertical los modelos se encuentran expresados
en distintos niveles de abstracción, por ejemplo es el caso en la transformación de un PIM a
PSM. Estos PSMs se pueden generar mediante una o más transformaciones. Un PSM es
producido a partir de un PIM más información adicional.
Basándose en el lenguaje en el cual se encuentran expresados los modelos de origen y
destino, se puede hablar también de transformaciones endógenas o exógenas. Las
transformaciones endógenas son aquellas transformaciones que comparten el mismo
metamodelo; si los metamodelos son diferentes las transformaciones se llaman exógenas. Si
en una transformación se utilizan varios modelos origen y/o varios modelos destino, entonces
pueden estar involucrados varios metamodelos diferentes [58].
Existen muchos caminos en los cuales las transformaciones pueden ser realizadas:
Construyendo manualmente el PSM a partir de un PIM.
De manera semiautomática, generando la estructura de un PSM y
completándolo a mano.
De manera automática, generando un PSM completo a partir del PIM.
Para las transformaciones automáticas se utilizan herramientas especializadas. Estas
herramientas tienen implementados distintos algoritmos de transformación para pasar de un
tipo de modelo a otro, pilar fundamental en MDA.
También es posible refinar un PSM transformándolo sucesivamente en PSMs de más
bajo nivel, hasta llegar al punto en que pueda ser transformado a código de manera directa.
Con la ayuda de las herramientas de transformación se puede obtener gran parte del código
46
del sistema para la plataforma elegida. El desarrollador sólo tendrá que añadir la
funcionalidad que no puede representarse con un PIM o PSM.
Un modelo se prepara utilizando tipos independientes de la plataforma. Los tipos
pueden ser parte de un marco de trabajo de software. Los elementos en el PIM son subtipos de
los tipos independientes de la plataforma. Para realizar la transformación una plataforma es
elegida y el mapeo entre los tipos independientes y los dependientes a la plataforma es
construido. Este mapeo incluye un conjunto de marcas. Las marcas se utilizan para marcar
elementos del modelo y para dirigir o controlar la transformación a una plataforma
determinada. Estas marcas son específicas de la plataforma por lo que no forman parte del
PIM. Los elementos en PSM son subtipos de los tipos específicos de plataforma.
Cuando se habla de transformación de metamodelos, un modelo se prepara utilizando
un lenguaje independiente de la plataforma especificada por un metamodelo. Una
especificación de una transformación para esta plataforma es preparada. Esta especificación
de transformación es en términos de una asignación entre los metamodelos. La Figura 3.3
muestra las relaciones entre los metamodelos, los modelos y las transformaciones.
Figura 3.3: Transformación de modelos y metamodelos
Como se mencionó anteriormente, a través de los motores de transformación se facilita
la evolución de modelos, transformando unos modelos a otros, según la reglas de
transformación entre metamodelos.
3.5 Arquitectura en capas
MDA no implica el uso de UML para la construcción de modelos, en su lugar MDA utiliza
MOF [54], ya que las definiciones de metamodelos son instancias del meta-metamodelo MOF
[55].
MOF un lenguaje de metamodelado, es decir MOF se utiliza crear metamodelos, y en
consecuencia es un elemento básico en MDA. Un lenguaje de modelado se define mediante
un metamodelo o descripción de los elementos del lenguaje y de las posibles relaciones entre
ellos.
47
Cada metamodelo define un lenguaje de modelado para un dominio específico, el cual
presenta una solución al modelado de distintos tipos de sistemas software. Como ejemplo se
puede observar el metamodelo UML para modelar la arquitectura de sistemas orientados a
objetos, o el metamodelo SPEM para modelar procesos software, entre otros.
Para comprender porque los metamodelos son instancias de MOF en la Figura 3.4 se
muestran los niveles de modelado de la arquitectura conceptual de MOF.
Figura 3.4: Ejemplo de las cuatro capas del metamodelo [50]5
El nivel del meta-metamodelado es la base en la jerarquía de metamodelado. La
responsabilidad principal de esta capa consiste en definir el lenguaje para la especificación de
un metamodelo. La capa a menudo se denomina como M3, y MOF es un ejemplo de un meta-
metamodelo. Un meta-metamodelo es típicamente más compacto que el metamodelo que
describe y, a menudo define varios metamodelos. En general, es conveniente que tanto el
meta-metamodelo y el metamodelo compartan constructores comunes. Sin embargo, cada
capa puede ser vista independientemente de otras capas. MOF es considerado como un
ejemplo de lenguajes dentro de este nivel [47]. Dicho lenguaje se define por la OMG con el
fin de definir constructores y mecanismos para definir metamodelos. Algunos de estos
constructores son: clases, atributos, asociaciones entre otros [50].
5 Model Driven Architecture TM – Applying MDA TM to Esterprise computing pag. 105
48
Un metamodelo es una instancia de un meta-metamodelo. La responsabilidad
principal de la capa metamodelo es la definición de un lenguaje para especificar modelos. La
capa se denomina a menudo M2 [47]. Algunos ejemplos de lenguajes que se encuentra en este
nivel son UML, Metamodelo Común de Almacenes de Datos (CWM) y Modelo de
Componentes CORBA, los cuales están expresados en MOF. De esta manera, los
constructores M2 son instancias de los constructores M3. En otras palabras, los constructores
definidos por los metamodelos son instancias de los constructores de MOF [50].
Un modelo es una instancia de un metamodelo. La responsabilidad principal de la capa
de modelo es definir los lenguajes que describen los dominios semánticos, es decir, permitir a
los usuarios modelar una amplia variedad de dominios. Los elementos que son modelados
residen fuera de la jerarquía del metamodelo. Esta capa se denomina a menudo como M1. Los
conceptos definidos en M1 especifican la clasificación para los elementos de M0.
Los elementos de la capa denominada M0 son instancias de un modelo particular, de
un sistema real, es decir son instancias de los elementos de M1. Se describe información del
dominio, es decir los elementos concretos. Un ejemplo de una instancia de la clase Cliente
sería “Juan Lucero”.
3.6 Estándares involucrados en MDA
En MDA, los PIM son inicialmente expresados en un lenguaje de modelado independiente de
la plataforma, por ejemplo con UML. El PIM es convertido a un PSM seleccionado. Luego a
partir del PSM, se genera el código del sistema en el lenguaje de programación deseado, por
ejemplo Java, C#, etc.
Para poder llevar a la práctica los conceptos subyacentes de MDA, la OMG define un
gran número de estándares [6] [57], algunos de los cuales ya han sido descriptos en las
secciones precedentes:
UML (Unified Modelling Language), es un Lenguaje de Modelado estándar
para visualizar, especificar, construir y documentar sistemas de software.
Adoptado por la OMG y publicado como estándar en el año 1997. Proporciona
un vocabulario para describir gran cantidad de sistemas. La mayoría de los
dominios pueden modelarse con UML.
CWM (Common Warehouse Metamodel), define un formato común de
intercambio para metadatos en data warehouse. Provee un lenguaje común y
definiciones de metamodelos para datos en data warehouse.
OCL (Object Constraint Language), lenguaje formal utilizado para describir
expresiones en modelos UML. Permite expresar consultas y restricciones sobre
modelos. Las expresiones OCL se evalúan y no tienen efectos secundarios.
49
MOF (Meta Object Facility), es el metamodelo facilitado por MDA como
vocabulario básico o meta-metamodelo. Proporciona un repositorio de modelos
que pueden ser utilizados para especificar y manipular modelos, manteniendo
la consistencia entre lo modelos manipulados en todas las fases de la
utilización de MDA.
QVT (Query/View/Transformation), es un estándar establecido para crear
consultas, vistas y transformaciones de modelos. Su especificación depende de
otros dos estándares de la OMG como son MOF y OCL. La utilización de la
especificación de QVT para especificar transformaciones, aporta reutilización
de tecnologías que siguen estándares.
XMI (XML Metadata Interchange), es el estándar para el intercambio,
manipulación e integración de datos y objetos XML. Su principal objetivo es
permitir un intercambio de meta-información entre herramientas de modelado
y repositorios de meta-información basados en MOF en entornos heterogéneos.
XMI provee un mapeo entre MOF y XML.
3.7 QVT
3.7.1 Introducción
Como se mencionó en las secciones anteriores un aspecto importante en el desarrollo dirigido
por modelos son las transformaciones de modelos, un proceso en el cual se convierte un
modelo en otro representando el mismo sistema. Una transformación de modelos es una
transformación de uno o más modelos fuentes a uno o más modelos destinos, cada uno
basados en sus metamodelos. Se puede decir entonces que instancias de un metamodelo
pueden ser transformadas en instancias de otro metamodelo. Una definición de
transformación es un conjunto de reglas de mapeo que en forma conjunta definen cómo un
modelo origen puede ser transformado en un modelo destino. Cada regla de mapeo describe
que uno o más elementos del modelo fuente deben ser transformados en elementos del
modelo destino. Cuando todas las reglas de mapeo han sido aplicadas la transformación se
considera completa.
El mapeo se utiliza para realizar la transformación de las instancias de los modelos a
ser mapeados. Éste describe las reglas a ser utilizadas para la transformación.
Anteriormente se señaló como la transformación de modelos es un proceso clave en
MDA. El lenguaje estándar que propone la OMG para expresar consultas y definir
transformaciones es QVT. Con QVT es posible definir transformaciones genéricas entre
metamodelos, de esta manera cualquier instancia de un metamodelo puede ser transformado
en una instancia de otro metamodelo. QVT se basa principalmente en la definición de un
lenguaje para consultas (Queries) sobre modelos MOF, la búsqueda de un estándar para
50
generar vistas (Views) que muestran aspectos específicos de los sistemas modelados, y la
definición de un lenguaje para la descripción de transformaciones (Transformations) de
modelos MOF. Con respecto a las consultas en los modelos: el lenguaje facilita consultas ad-
hoc para selección y filtrado de elementos de modelos. Para las vistas en metamodelos: el
lenguaje permite la creación de vistas de metamodelos sobre los que se define la
transformación. Y para las transformaciones de modelos: el lenguaje permite la definición de
transformaciones, a través de relaciones entre un metamodelo fuente y un metamodelo
destino.
QVT permite definir transformaciones genéricas entre metamodelos de manera precisa
y estos metamodelos se encuentran definidos en MOF. Una característica importante es que
las transformaciones pueden ser bidireccionales.
La especificación QVT se define a través de dos dimensiones ortogonales: la
dimensión del lenguaje y la dimensión de interoperabilidad, con cada dimensión
especificando una serie de niveles. La intersección de niveles de las dos dimensiones define
un punto de compatibilidad QVT (QVT-compliance). La dimensión del lenguaje define los
lenguajes de transformación presentes en la especificación QVT: Relations, Core y
Operational Mappings. La principal diferencia entre ellos radica en su naturaleza declarativa o
imperativa. En la dimensión de interoperabilidad se hallan las características que hacen
posible que una herramienta interactúe con otra que cumpla con el estándar. Estas
características son: sintaxis ejecutable, XMI ejecutable, sintaxis exportable y XMI exportable:
La sintaxis ejecutable se refiere a una implementación que permita fácilmente
la importación o lectura, y posterior ejecución de la descripción de la sintaxis
concreta de una transformación definida en el lenguaje dado por la dimensión
del lenguaje.
XMI ejecutable se refiere a que una implementación debe proveer facilidad
para importar o leer, y posteriormente ejecutar una serialización XMI de una
transformación que concuerda con el metamodelo MOF del lenguaje dado por
la dimensión del lenguaje.
La sintaxis exportable establece que una implementación debe proveer
facilidad para exportar una transformación modelo a modelo en la sintaxis
concreta del lenguaje dado por la dimensión del lenguaje.
XMI exportable se refiere a que una implementación debe permitir facilidad
para exportar transformaciones modelo a modelo como serializaciones XMI
que concuerda con el metamodelo MOF del lenguaje dado por la dimensión del
lenguaje [48].
51
3.7.2 Visión General
La especificación QVT tiene una naturaleza híbrida porque es declarativa e imperativa, con la
parte declarativa dividida en una arquitectura de dos capas que forma el marco de trabajo para
la ejecución semántica de la parte imperativa. Las dos capas de la arquitectura de la parte
declarativa de QVT son:
Un metamodelo Relations conocido, y un lenguaje declarativo que soporta pattern
matching (coincidencia de patrones) de objetos complejos y creación de plantillas (template)
de objetos. La trazabilidad entre los elementos del modelo involucrados en la transformación
se crea implícitamente.
Un metamodelo Core, y un lenguaje declarativo definido usando extensiones mínimas
de EMOF (Essential MOF) y OCL. Todas las clases de trazabilidad están explícitamente
definidas como modelos de MOF, y la creación y eliminación de una instancia de clase de
trazabilidad se define de la misma manera que la creación y eliminación de cualquier otro
objeto. La Figura 3.5 muestra los metamodelos antes mencionados y sus relaciones.
Figura 3.5: Relaciones entre los metamodelos QVT
El lenguaje Relations provee una especificación declarativa de las relaciones entre
modelos MOF. Además de soportar pattern matching de objetos complejos e implícitamente
crear clases de trazabilidad y sus instancias guardando todo lo que sucede en una ejecución de
una transformación, tiene una sintaxis gráfica concreta. La semántica de Relations se define
con una combinación de lenguaje natural y lógica de primer orden.
Core es un lenguaje/modelo que sólo admite pattern matching sobre un conjunto de
variables, evaluando condiciones sobre variables de un conjunto de modelos. Core trata a
todos los elementos del modelo origen, del destino y de trazabilidad de forma simétrica y es
igualmente potente que el lenguaje Relations. Su semántica puede ser definida más
simplemente, aunque las descripciones de la transformación descripta utilizando Core son
más detalladas. Igualmente, los modelos de trazabilidad deben ser explícitamente definidos y
no son deducibles desde la descripción de la transformación, como ocurre en el lenguaje
Relations.
52
La flecha de la Figura 3.5 entre Relations y Core muestra que existe la posibilidad de
transformar una especificación de transformación en el lenguaje Relations al lenguaje Core.
Además de los lenguajes declarativos Relations y Core que tiene la misma semántica
en dos niveles distintos de abstracción, existen dos mecanismos para invocar
implementaciones imperativas de transformaciones desde Relations o Core: un lenguaje
estándar Operational Mappings, como también una implementación (no estándar) llamada
Black-box MOF Operation.
El lenguaje Operational Mappings está especificado como un estándar para proveer
implementaciones imperativas. La sintaxis del lenguaje QVT Operational Mappings
proporciona construcciones que suelen encontrarse en lenguajes imperativos (bucles,
condiciones, etc.). Además proporciona extensiones OCL con efectos colaterales que
permiten un estilo más procedural y una sintaxis concreta que hace a la programación más
familiar.
Operational Mappings puede ser utilizado para implementar una o más Relations
desde una especificación Relations cuando sea difícil proporcionar una especificación
declarativa. Estas operaciones pueden invocar otras operaciones de mappings siempre con el
objetivo de crear trazabilidad entre los elementos de los modelos. Una transformación escrita
utilizando operaciones de mappings es llamada transformación operacional.
Las operaciones MOF pueden derivarse desde Relations haciendo posible integrarlas
con cualquier implementación de una operación MOF con la misma firma. Esto es
beneficioso por varias razones:
Permite codificar algoritmos complejos en cualquier lenguaje de programación
vinculado a MOF.
Permite el uso de librerías específicas de dominios para calcular propiedades
del modelo. Por ejemplo, en matemáticas, en ingeniería y en otros dominios los
cuales almacenan algoritmos específicos, que serían muy complejos de
expresar utilizando OCL.
Permite el ocultamiento de la implementación de algunas partes de la
transformación.
Sin embargo, esta integración puede ser peligrosa porque la implementación asociada
a la integración puede romper el encapsulamiento ya que tiene acceso a las referencias de
objetos en los modelos.
Las implementaciones Black-box no tienen una relación implícita a Relations, y cada
Black-box debe invocar explícitamente a algún servicio de transformación que corresponda a
ese Relation, si fuera requerido [48]. Además Black-box se utiliza también para invocar
53
servicios de transformación expresados en otros lenguajes como por ejemplo XSLT, XQuery,
etc. con el fin de integrar bibliotecas existentes no compatibles con QVT.
3.7.3 Lenguaje Relations
Como se mencionó anteriormente, el lenguaje Relations permite construir una especificación
declarativa de las relaciones entre metamodelos MOF. Estas relaciones llevan a cabo la
transformación y soportan pattern matching de objetos complejos y templates de creación de
objetos.
Una relación establece un vínculo entre elementos de los modelos candidatos y
consiste de dos o más dominios. Un modelo candidato es cualquier modelo que forme parte
de un tipo de modelo o metamodelo. Los modelos candidatos tienen un nombre y los tipos de
los elementos que pueden contener. Estos elementos estarán restringidos por el paquete
(metamodelo) al que se hace referencia en la declaración del modelo candidato. La Figura 3.6
muestra un ejemplo [48] de la declaración de una transformación:
Figura 3.6: Declaración de una transformación en QVT-Relations
Como muestra el ejemplo, una transformación lleva el nombre de uml2Rdbms, y toma
dos parámetros los cuales son los modelos candidatos, uml y rdbms. El modelo uml es una
instancia del metamodelo SimpleUML y el modelo rdbms será una instancia del metamodelo
SimpleRDBMS. En el contexto de transformación el tipo de modelo está definido por su
metamodelo. Los metamodelos del ejemplo pueden observarse en la Figura 3.7 y 3.8
respectivamente.
transformation uml2Rdbms (uml : SimpleUML, rdbms : SimpleRDBMS)
54
Figura 3.7: Metamodelo SimpleUML
Figura 3.8: Metamodelo SimpleRDBMS
55
Una transformación (transformation) puede invocarse tanto para comprobar la
consistencia de los modelos como para transformar un modelo en otro. El procedimiento de
transformación se basa en comprobar que todas las relaciones definidas en esa transformación
se satisfagan y aquellas relaciones que no se cumplan, se intenta cumplirlas creando,
eliminando o modificando el modelo destino forzando el cumplimiento de estas relaciones.
Las relaciones (relations) en una transformación definen las restricciones que deben satisfacer
los elementos de los modelos candidatos.
Una transformación invocada se ejecutará en una dirección particular seleccionando
uno de los modelos candidatos como modelo destino u objetivo. El modelo destino puede
estar vacío o contener elementos para ser relacionados por la transformación. Como la
ejecución de las transformaciones puede ser bidireccional, la dirección se establece por el
conjunto de dominios que se asocian con el tipo de modelo de destino. Cada dominio define
un modelo candidato. Un dominio (domain) es una variable con tipo que puede hacer
matching en una instancia de un metamodelo dado. Un dominio tiene un patrón que puede ser
visto como un grafo de nodos de objetos, cuyas propiedades y links de asociación se originan
de una instancia del tipo del dominio. Un patrón contiene variables, asignaciones y predicados
que los elementos del modelo vinculados a esas variables deben satisfacer para lograr una
correspondencia válida de ese patrón. Un predicado se puede evaluar como falso, verdadero o
indefinido. Un patrón de dominio (domain pattern) puede considerarse como una plantilla
para objetos, y sus propiedades han de ser establecidas, modificadas o creadas en un modelo
candidato para satisfacer la relación.
La Figura 3.9 muestra una relación en el lenguaje QVT-Relations. En él se declaran
dos dominios que corresponden a elementos de los modelos uml y rdbms. Cada dominio
especifica un patrón simple, un paquete con un nombre y un esquema con un nombre. Las
propiedades name se corresponden con la misma variable pn, lo que implica que deberían
tener el mismo valor.
Figura 3.9 Declaración de una relación y dominios checkonly y enforce en QVT-Relations
Un dominio puede estar marcado como checkonly o enforce. Si un dominio se define
como checkonly, cuando se ejecute la transformación en esa dirección sólo se comprobará si
existe una correspondencia válida en el modelo relevante que satisfaga la relación; si el
dominio está marcado como enforce cuando una transformación se ejecuta en esa dirección, si
la comprobación falla, se modifica el modelo destino, creando, borrando o modificando sus
elementos para lograr que satisfaga la relación. En el ejemplo, el dominio para el modelo uml
está marcado como checkonly y el dominio para el modelo rdbms está marcado como enforce.
relation PackageToSchema {
checkonly domain uml p: Package {name=pn}
enforce domain rdbms s: Schema {name=pn}
}
56
Si se está ejecutando en la dirección a uml y existe un esquema en rdbms y en uml no existe
un paquete con el mismo nombre, se detectaría una inconsistencia pero no se crearía el
paquete ya que el modelo uml es checkonly y no enforce. No obstante, si se está ejecutando en
dirección a rdbms, entonces para cada paquete en el modelo de uml, la relación primero
comprobará si existe un esquema con el mismo nombre en el modelo rdbms, si no es así, se
creará un nuevo esquema en ese modelo con el mismo nombre del paquete en uml. La
aplicación de las reglas sólo depende del dominio destino.
Además una relación especifica la relación entre los elementos de modelos candidatos,
la cual consiste en dos o más dominios, pudiendo estar limitada por dos conjuntos de
predicados llamados: cláusulas when y clausulas where. La Figura 3.10 muestra su uso:
Figura 3.10: Declaración de cláusulas when, where y Pattern matching en QVT-Relations
La cláusula when establece las condiciones que se necesitan para satisfacer la relación,
es decir, la relación ClassToTable se cumplirá sólo cuando se satisfaga la relación
PackageToSchema, o en otras palabras, la relación se cumplirá cuando el paquete contiene la
clase y el esquema contiene la tabla. La cláusula where define la condición que deben cumplir
todos los elementos que intervienen en la relación, y tiene el poder de restringir cualquiera de
las variables en la relación y sus dominios. Por lo tanto, siempre que se cumpla la relación
ClassToTable, la relación AttributeToColumn también se cumplirá. En otras palabras se puede
relation ClassToTable
{
domain uml c:Class {
namespace = p:Package { },
kind = ’Persistent’,
name = cn
}
domain rdbms t:Table {
schema = s:Schema { },
name = cn,
column = cl:Column {
name = cn+’_tid’,
type=’NUMBER’ },
primaryKey = k:PrimaryKey {
name = cn+’_pk’,
column = cl }
} when {
PackageToSchema(p,s);
} where {
AttributeToColumn(c,t);
}
}
57
decir que la cláusula where establece que tras la aplicación de la relación ClassToTable se
procederá a la ejecución de la relación AttributeToColumn.
Las cláusulas when y where pueden contener cualquier expresión OCL además de las
expresiones de invocación de la relación. La invocación de relaciones permite componer
relaciones complejas a partir de relaciones más simples.
Una transformación puede contener dos tipos de relaciones: relaciones top-level y
relaciones no-top-level (ver Figura 3.11). La ejecución de una transformación requiere que
todas sus relaciones top-level se cumplan, mientras que las relaciones no-top-level se deben
cumplir sólo cuando son invocadas directa o indirectamente a través de la cláusula where de
otra relación.
Figura 3.11: Declaración de relaciones top-level y no-top-level en QVT-Relations
La distinción sintáctica entre una relación top-level y una no-top-level es la palabra
clave top. En la figura anterior, las relaciones PackageToSchema como ClassToTable son
relaciones top-level mientras que AttributeToColumn es una relación no-top-level.
Como se dijo anteriormente, las relaciones soportan pattern matching de objetos
complejos. Los patrones asociados a los dominios reciben el nombre de object template
expressions. Para mostrar cómo trabajan los patrones se mostrará nuevamente el ejemplo
antes visto de ClassToTable presentada en la Figura 3.10.
La relación ClassToTable define varias expresiones de tipo object template expression
que se utilizarán para hacer pattern matching en los modelos candidatos. En la Figura 3.10 se
puede observar el object template expression asociado al dominio de uml.
Un object template expression une elementos de un modelo candidato con variables
declaradas en el dominio. Esta expresión debe efectuarse en un contexto donde algunas de las
variables del domino estén vinculadas con elementos de un modelo. En este ejemplo el object
template expression sólo encuentra enlaces para tres variables del dominio. Estas variables
son: c, p, cn. El pattern matching ligará todas las variables de la expresión comenzando desde
la variable raíz del domino c de tipo Class. La variable p estará ligada como resultado de la
evaluación de la expresión PackageToSchema(p,s) en la cláusula when. El proceso de
matching consiste en filtrar todos los objetos de tipo Class en el modelo uml, eliminando
Transformation uml2Rdbms (uml : SimpleUML, rdbms : SimpleRDBMS) {
top relation PackageToSchema { . . . }
top relation ClassToTable { . . . }
relation AttributeToColumn { . . . }
}
58
todos los objetos que no tenga los mismos valores que el object template expression. En el
ejemplo anterior, cualquier Class con propiedad kind distinta a „Persistent’ será eliminada.
Al comparar propiedades con variables como name=cn se pueden observar dos casos:
si la variable cn tiene un valor asignado, entonces cualquier Class que no tenga
el mismo valor para su propiedad name será eliminada,
si la variable cn es libre, como sucede en el ejemplo, se le asignará el valor de
la propiedad name de todas las clases.
Luego, el proceso de matching avanza hacia las propiedades cuyos valores son
comparados con object template expressions anidados. Esto puede observarse con la
propiedad namespace = p: Package que hará matching con aquellas clases cuya propiedad
namespace tenga una referencia no nula a un Package. Al mismo tiempo, la variable p
apuntará al Package. Sin embargo, en el ejemplo la variable p toma un valor en la cláusula
when por lo que sólo hará pattern matching con aquellas clases cuyas propiedades namespace
tengan una referencia al mismo paquete al que se refiere p.
En una invocación a una relación, puede haber varios matchings válidos para un
template expression, la manera de procesar esta multiplicidad depende de la dirección en la
que se ejecute la relación. Por ejemplo, si se ejecuta la relación ClassToTable y el modelo
rdbms está marcado como destino, entonces por cada matching válido del dominio uml, tendrá
que existir al menos un matching válido del dominio rdbms que satisfaga la cláusula where. Si
para un matching válido del dominio uml, no existe un matching válido del dominio rdbms,
entonces como el dominio rdbms está marcado como enforce, se crean objetos y las
propiedades se definen en el template expression asociado con el dominio rdbms. De la
misma manera, para cada matching válido del dominio rdbms, tendrá que existir al menos un
matching válido del dominio uml que satisfaga la cláusula where, esto es porque el dominio
uml está marcado como checkonly; en otro caso los objetos se eliminarán del modelo rdbms
por lo que no seguirá siendo un matching válido.
Como se mencionó anteriormente, un object template expression también se puede
utilizar como plantilla para crear un objeto en un modelo destino. Se utiliza un object template
expression del dominio destino como plantilla para crear objetos en el modelo destino, cuando
para un matching válido de un patrón del dominio origen, no existe un matching en el patrón
del dominio destino. Por ejemplo, cuando se ejecuta ClassToTable con rdbms como modelo
destino, el object template expression se utiliza para crear objetos en el modelo rdbms (ver
Figura 3.12).
59
t: Table {
schema = s: Schema { },
name = cn,
column = cl: Column {
name=cn+’_tid’,
type=’NUMBER’ },
primaryKey = k: PrimaryKey {
name=cn+’_pk’,
column=cl }
}
Figura 3.12: Creación de objetos usando patrones en QVT-Relations
La plantilla asociada con Table especifica que un objeto de este tipo debe ser creado
con las propiedades schema, name, column y primaryKey inicializadas a los valores del object
template expression. Similarmente, las plantillas asociadas con Column y PrimaryKey
especifican como deben crearse sus respectivos objetos. Cuando se crean objetos, se debe
tener cuidado de que no se creen objetos duplicados cuando los objetos requeridos ya existen.
Sin embargo, en muchas ocasiones, se requiere actualizar objetos existentes, lo que deriva en
un problema sobre cuándo actualizar objetos existentes o permitir la creación de un objeto.
Como se mencionó anteriormente, QVT es un lenguaje que se utiliza para transformar
un modelo en otro modelo, y estos modelos están descriptos en un lenguaje más abstracto
llamado metamodelo. Las transformaciones en QVT se realizan a través de reglas escritas a
nivel de metamodelo ya que éste permite describir transformaciones genéricas entre
metamodelos. A través de estas reglas cualquier instancia de un metamodelo puede ser
transformado en una instancia de otro metamodelo. Para poder comprender las reglas de
transformación, el siguiente capítulo describe las componentes más importantes de los
metamodelos requeridas en este trabajo de tesis.
60
Capítulo 4
Metamodelos
En el contexto de transformación, los tipos de modelos son definidos por sus metamodelos y
por un conjunto opcional de expresiones de restricción. Los metamodelos, que a su vez son
instancias de meta-metamodelos, tienen como función la definición de un lenguaje para la
especificación de modelos. Es imprescindible tener un lenguaje con una sintaxis y semántica
precisa para la descripción de modelos. El presente capítulo explica los principales conceptos
de los metamodelos BPMN2 y ESTECO, dando particular énfasis en las tareas y en los datos
de entrada y salida a nivel proceso y a nivel actividad.
4.1 Introducción
Los metamodelos BPMN2 y ESTECO están expresados en MOF (Meta Object Facility) [54].
MOF es un lenguaje muy abstracto y pequeño que permite describir metamodelos.
Antes de explicar los metamodelos utilizados en esta tesis, es necesario distinguir
entre metamodelos y modelos. Se debe recordar que un modelo es una instancia de un
metamodelo y puede a su vez ser utilizado como un metamodelo de otro modelo y así
sucesivamente. Un modelo contiene elementos y estos elementos son instancias de los
elementos del metamodelo [14].
Los metamodelos son los encargados de definir la semántica que especifica como los
elementos del modelo serán instanciados.
En la Figura 4.1 se puede observar la metaclase Class definida en el metamodelo
MOF. Este elemento es instanciado en un modelo como la clase Task, el cual a su vez es
instanciada con la clase Calculator.
Figura 4.1: Ilustración de instancias en MOF
Class Task
<<instanciaDe>> <<instanciaDe>>
Calculator
61
4.2 Metamodelo BPMN2
El objetivo principal de BPMN2 es proporcionar una notación que sea fácilmente
comprensible por todos los usuarios de negocio. El metamodelo BPMN2 expresa los
elementos de modelado que permiten construir instancias de modelos de procesos de negocio
en BPMN2.
4.2.1 Principales elementos del metamodelo BPMN2
Como se dijo anteriormente, los tipos de modelos son definidos por sus metamodelos. Para
poder comprenderlos es necesario conocer la estructura del metamodelo que los define. A
continuación se describen los principales elementos del metamodelo BPMN2.
La clase Definitions es la clase más externa que contiene a todos los elementos de
BPMN2. Este objeto define el alcance de visibilidad y el espacio de nombres para todos los
elementos contenidos en él. Además este elemento hereda los atributos y las asociaciones de
la clase BaseElement.
BaseElement es la superclase abstracta para la mayoría de los elementos de BPMN2.
Esta clase proporciona el identificador y la documentación.
RootElement es la superclase abstracta, sin atributos, para todos los elementos que
están contenidos dentro de Definitions. Además este elemento también hereda los atributos y
las asociaciones de BaseElement.
La clase Import es utilizada para referenciar elementos externos, ya sea elementos
BPMN2 contenidos en otros Definitions u otros elementos. Las importaciones deben ser
definidas explícitamente. Esta clase posee tres atributos los cuales identifican:
el tipo del documento que se importará (importType). Si se importan esquemas
XML el valor del atributo debe ser http://www.w3.org/2001/XMLSchema, si se
importan documentos WSDL 2.0 el valor debe ser
http://www.w3.org/TR/wsdl20 y si se importan documentos BPMN 2.0 el valor
deberá ser http://www.omg.org/spec/BPMN/20100524/MODEL,
la ubicación del elemento importado (location) y
el espacio de nombres del elemento importado (namespace).
Elementos de BPMN2, como objetos de datos (dataObjects) y mensajes, representan
ítems que son manipulados, transferidos, transformados o almacenados durante el flujo del
proceso. Estos ítems pueden ser objetos físicos, como una parte de un automóvil, o elementos
de información como un catálogo de automóviles. Esta diferenciación es almacenada en el
atributo itemKind de la clase ItemDefinition. Una característica importante de los ítems en el
proceso es su estructura. BPMN2 no requiere un formato particular para esta estructura de
datos, pero sí como defecto tienen un esquema XML. Un elemento ItemDefinition puede
especificar una referencia a donde está definida la estructura (structureRef). En los casos en
62
que la estructura de datos representa una colección, la multiplicidad puede ser proyectada en
el atributo IsCollection. Si el atributo está establecido como verdadero pero en realidad la
estructura de datos no es una colección, el modelo es considerado inválido. Aquellas
herramientas que soportan el estándar BPMN2 pueden comprobar estas inconsistencias. El
valor por defecto de este atributo es falso. Los ItemDefinition están contenidos en Definitions.
La Figura 4.2 muestra los elementos descriptos anteriormente junto con sus relaciones.
Figura 4.2: Organización de los principales elementos BPMN2
4.2.2 Metamodelo y la Metaclase Process
La Figura 4.3 muestra los elementos fundamentales a la hora de modelar un proceso de
negocio. A continuación se describen algunos de ellos.
Un proceso (Process) describe una secuencia o flujo de actividades en una
organización con el objetivo de llevar a cabo un trabajo. El paquete Process contiene clases
que son utilizadas para modelar el flujo de actividades, eventos y compuertas, y cómo ellos
están ordenados dentro del proceso. Un proceso está definido dentro del objeto Definitions.
Por otro lado, un proceso es un objeto CallableElement, este permite que el proceso
pueda ser referenciado o reutilizado por otros procesos a través del constructor Call Activity.
En otras palabras, se puede decir que un proceso es un elemento reutilizable, el cual puede ser
importado y utilizado dentro de otros elementos Definitions.
El elemento process hereda los atributos y las asociaciones de la clase
CallableElement y de la clase FlowElementsContainer. Los elementos relacionados con
63
process pueden observarse en la Figura 4.3.
FlowElementsContainer es una superclase abstracta la cual define el superconjunto de
elementos que están contenidos en los diagramas BPMN2. Un FlowElementsContainer
contiene FlowElements, los cuales son: eventos, compuertas, flujos de secuencia, actividades,
entre otros. Además hereda los atributos y las asociaciones de BaseElement.
FlowElement es la superclase abstracta para todos los elementos que pueden aparecer
en un flujo de proceso, los cuales son FlowNode (eventos, compuertas, flujos de secuencia,
actividades, objetos de datos y asociaciones de datos). El elemento FlowElement hereda los
atributos y las asociaciones de BaseElement.
Figura 4.3: Algunos elementos relacionados con Process
Los flujos de secuencia son utilizados para mostrar el orden de ejecución de los
elementos en un proceso. Cada flujo de secuencia tiene un solo origen (sourceRef) y un solo
destino (targetRef) que deben pertenecer al conjunto de FlowElement. Ambos son instancias
de FlowNode, es decir, deben ser eventos, actividades o compuertas, como muestra la Figura
4.3. El elemento SequenceFlow hereda los atributos y las asociaciones de FlowElement.
Un flujo de secuencia que tiene como origen una compuerta exclusiva, inclusiva o
compleja, o una actividad puede ser definido como un flujo por defecto.
El elemento FlowNode se utiliza para proporcionar un solo elemento como origen y un
solo elemento como destino de un flujo de secuencia. Esta restricción se puede observar en la
64
Figura 4.3 en las asociaciones desde SequenceFlow a FlowNode donde la multiplicidad es uno
en los roles targetRef y sourceRef. Sólo los elementos que heredan de FlowNode pueden estar
conectados a través de un flujo de secuencia.
4.2.3 Metaclase Event y sus relaciones
Un evento es algo que sucede durante el curso de un proceso. Los eventos afectan el flujo de
los procesos. Los eventos se utilizan en distintas partes del proceso, pueden mostrar el
comienzo de una actividad, el fin de una actividad, un mensaje que llega, la interrupción de un
proceso, etc. La clase Event representa a los eventos y hereda los atributos y las asociaciones
de FlowNode y éste a su vez de FlowElement.
Existen tres tipos de eventos:
1. inicio: indica que un proceso comienza,
2. fin: indica donde finaliza un proceso,
3. intermedio: indica que algo sucede después de que el proceso ha comenzado y antes
de que termine el mismo.
Dentro de estos tres tipos, los eventos pueden diferenciarse en los que capturan un
disparador que los activará o los que producen un resultado. Los eventos que capturan un
disparador son los eventos de inicio y algunos eventos intermedios. Estos caen en la categoría
CatchEvent. Los eventos que producen un resultado son los eventos de fin y algunos
intermedios y estos caen en la categoría ThrowEvent.
La Figura 4.4 muestra el diagrama de clases donde se modela la clase Event junto con
algunas de sus relaciones. Aquí se observa como Event hereda de FlowNode y éste de
FlowElement. Además se puede observar los distintos tipos de eventos, ya sean capturadores
de disparos (CatchEvent) o los que arrojan un resultado (ThrowEvent).
65
Figura 4.4: Clase Event y sus relaciones
4.2.4 Metaclase Activity y sus relaciones
Como se mencionó en el capítulo 2, una actividad representa una unidad de trabajo que es
realizada o ejecutada dentro de un proceso de negocio. Las actividades generalmente
requieren un tiempo para su ejecución, pueden necesitar recursos, suelen requerir algún tipo
de entrada y por lo general producen algún tipo de salida. En BPMN2 las actividades pueden
ser: tareas (tareas atómicas), sub-procesos (no atómicas - tareas compuestas) y Call-Activity
(subprocesos reutilizables). La clase Activity es una clase abstracta, subclase de FlowElement,
es por ello que hereda los atributos y las asociaciones de esta clase. La clase Activity es la
superclase para todos los tipos concretos de ésta. Ellos especifican una semántica adicional.
La Figura 4.5 muestra la clase Activity con algunas de sus relaciones. En ella se puede
observar como hereda de la clase de FlowElement a través de FlowNode. A continuación se
explican algunos de los nombres de roles que aparecen en la Figura antes mencionada:
ioSpecification: Este elemento define las entradas y salidas que pertenecen a
los conjuntos InputSets y OutputSets de las actividades, como se verá más
adelante.
properties: Define las propiedades que pueden añadirse a las actividades. Las
mismas están contenidas dentro de Activity.
resources: Define el recurso que llevará a cabo o que será responsable de la
actividad.
dataInputAssociations: Son referencias a DataInputAssociations. Un
DataInputAssociation define cómo los datos de entrada del
66
InputOutputSpecification de la actividad son ingresados.
dataOutputAssociations: Son referencias a los DataOutputAssociations.
Figura 4.5: Clase Activity y sus relaciones
Una tarea es una actividad atómica dentro de un flujo de proceso. Ésta representa una
acción, no una función ni un estado. Una tarea se utiliza cuando el trabajo en el proceso no
puede ser dividido en mayor nivel de detalle. La clase Task hereda los atributos y asociaciones
de la clase Activity. La clase Task no posee atributos ni asociaciones. Existen diferentes tipos
de tareas para representar los distintos tipos de comportamiento que ellas pueden tener (ver
Figura 4.6). A continuación se detallan estos tipos:
Abstracta (None): Tarea genérica o indefinida, es decir que no está
especificada.
Usuario (User): Tarea que lleva a cabo un humano con la ayuda de una
aplicación de software y que está programada a través de una lista de tareas.
Manual (Manual): Es una tarea que se espera llevar a cabo sin la ayuda de
ningún motor de ejecución de procesos de negocio o cualquier otra aplicación.
Envío (Send): Está diseñada para enviar un mensaje a un participante externo
(en relación al proceso). Una vez que el mensaje ha sido enviado, la tarea se
completa.
Recepción (Receive): Está diseñada para esperar que llegue un mensaje de un
participante externo (en relación al proceso). Una vez que el mensaje ha sido
recibido, la tarea se completa.
Servicio (Service): Es una tarea que utiliza algún tipo de servicio, el cual puede
ser: servicio web o una aplicación automatizada. Esta tarea incluye los
atributos y asociaciones de Activity pero a su vez introduce restricciones
cuando el servicio hace referencia a una operación, es por ello que en la Figura
67
4.6 puede observarse la clase Operation.
Script: Este tipo de tarea se ejecuta mediante un motor de procesos de negocio.
El modelador o implementador define el script en un lenguaje que el motor
puede interpretar. Cuando la tarea está lista para comenzar, el motor ejecutará
el script. Cuando el script fue ejecutado, la tarea finaliza. Esta clase posee dos
atributos adicionales: scriptFormat: el cual define el formato del script y que
además debe especificar si el script es provisto o no, y el atributo script el cual
representa si ha sido incluido éste o no. En caso de que no esté incluido se
comporta como una tarea abstracta.
Regla de Negocio (BusinessRule): Son expresiones formuladas a través de
reglas que serán ejecutadas a través de un motor. El InputOutputSpecification
de la tarea permitirá al proceso enviar datos y recibir datos desde el motor de
reglas de negocios.
El atributo implementation que poseen algunas de las clases de la Figura 4.6
especifican la tecnología que será utilizada para implementar esa tarea.
La Figura 4.6 muestra los distintos tipos de tareas junto con sus atributos y las
asociaciones adicionales que poseen algunas de ellas.
Figura 4.6: Clase Task junto con sus tipos y sus relaciones
Como se mencionó en el capítulo 2, un Call Activity identifica un punto en el proceso
donde otro proceso o una tarea global son utilizadas. La Figura 4.5 muestra como la clase Call
Activity hereda los atributos y asociaciones de la clase Activity.
68
Un sub-proceso es una actividad cuyos datos internos han sido modelados con
actividades, compuertas, eventos y flujos de secuencia (ver Figura 4.7). Esta clase hereda de
la clase FlowElementsContainer y ésta, como se dijo anteriormente, es una superclase
abstracta la cual define el superconjunto de los elementos que están contenidos en los
diagramas BPMN2. FlowElementsContainer posee una asociación con FlowElement. Es así
como un sub-proceso puede poseer eventos, compuertas, flujos de secuencia y actividades.
Figura 4.7: Clase Sub-Process
4.2.5 Metaclase Gateway y sus relaciones
Las compuertas son utilizadas para controlar los flujos de los procesos a través de los flujos
de secuencia que divergen o convergen dentro en un proceso. Si el flujo no tiene que ser
controlado, entonces no son necesarias las compuertas. Además las compuertas pueden tener
múltiples entradas y múltiples flujos de salida. Las compuertas pueden definir todos los tipos
de comportamientos de los flujos de secuencia en un proceso de negocio: exclusivo, inclusivo,
paralelo, complejo y basados en eventos. La Figura 4.8 muestra estos tipos de compuertas.
69
Figura 4.8: Diagrama de clase para los tipos de compuertas
Las compuertas inclusivas, exclusivas y complejas poseen varios flujos de secuencia
salientes, si ninguno de ellos evalúan en verdadero se utiliza un flujo adicional por defecto
como se puede observar en la Figura 4.8 donde algunas de las asociaciones hacia la clase
SequenceFlow poseen como rol default. Este flujo por defecto no debe poseer ninguna
expresión de condición. Además en la Figura 4.8 se puede observar un rol
activationCondition, éste determinará qué combinación de tokens entrantes deben
sincronizarse para activar la compuerta compleja.
4.2.6 Objetos de datos en el metamodelo
En muchas ocasiones es necesario modelar los datos en un proceso de negocio, requiriendo
que estos datos puedan ser creados, manipulados o utilizados para ejecutar las actividades que
participan en él. Este requerimiento se implementa a través de objetos de datos (data objects),
tipo de ítems (ItemDefinition), propiedades (propierties), datos de entrada (data inputs), datos
de salida (data outputs), conjuntos de entrada (inputSets), conjuntos de salida (outputSets), y
asociaciones de datos (data associations).
Los elementos o ítems que pueden almacenarse o transportarse durante la ejecución
generalmente son referenciados como elementos “itemAware”. Estos elementos poseen una
definición de tipo (ItemDefinition), sin embargo un elemento itemAware puede ser sub-
especificado, lo que significa que colocar el elemento ItemDefinition es opcional.
En BPMN2 los elementos definidos como itemAware son: objetos de datos,
referencias a objetos de datos, almacenes de datos, propiedades, datos de entrada y datos de
70
salida. Estos elementos pueden observarse en la Figura 4.9.
Figura 4.9: Clase ItemAwareElement
Como se puede observar en la Figura 4.9 el elemento ItemAwareElement hereda los
atributos y las asociaciones de la clase BaseElement. Además se muestra una relación entre la
clase ItemAwareElement y la clase ItemDefinition con un nombre de rol ItemSubjectRef. Esto
significa que un objeto de la clase ItemAwareElement puede poseer un atributo itemSubjectRef
y éste define el tipo del ítem (itemKind) que podrá ser físico o información, que puede ser una
colección (isCollection) o no, y que tendrá una referencia a un elemento (structureRef).
Las actividades y los procesos generalmente necesitan datos para ejecutarse. Además,
pueden producir datos o resultados durante la ejecución. Los requerimientos de datos son
capturados como datos de entradas (dataInputs) en los conjuntos de entradas (InputSets). Los
datos que se producen son capturados como datos de salidas (dataOutputs) en los conjuntos
de salidas (OutputSets). Todos estos elementos son agrupados en una clase llamada
InputOutputSpecification. Los procesos poseen un elemento InputOutputSpecification en el
cual están alojados todos los datos de entrada y salida que participan en todo el proceso. Las
actividades también poseen este elemento. En él estarán los datos de entrada y salida que
participan en esa actividad en particular. Cabe aclarar que no todos los tipos de actividades
definen datos de entrada y salida, sólo las tareas y los elementos CallableElements (tareas
globales y procesos) pueden definir este requerimiento. El elemento InputOutputSpecification
hereda los atributos y las asociaciones de BaseElement. La Figura 4.10 muestra las relaciones
vinculadas con la clase InputOutputSpecification.
71
Figura 4.10: Relaciones vinculadas a InputOutputSpecification
Los datos de entradas (data inputs) se utilizan como entrada de un
InputOutputSpecification. Como se puede observar en la Figura 4.10 puede haber múltiples
datos de entrada asociados a un InputOutputSpecification. Un elemento DataInput es un
elemento itemAware, en consecuencia hereda los atributos y las asociaciones de BaseElement.
Los datos de salida (data outputs) son datos que se producen y que son asociados a un
InputOutputSpecification. Puede haber múltiples datos de salida asociados a un
InputOutputSpecification, como se observa en la Figura 4.10. Un elemento DataOutput es un
elemento itemAware, en consecuencia hereda los atributos y las asociaciones de BaseElement.
Un conjunto de entradas (inputSet) es una colección de datos de entradas que juntos
definen un conjunto válido de datos de entradas para una InputOutputSpecification. Un
InputOutputSpecification debe tener al menos un conjunto de entradas. Un conjunto de
entradas puede hacer referencia a cero o más datos de entradas. Un dato de entrada puede
asociarse a múltiples conjuntos de entradas, pero siempre debe hacer referencia al menos a un
conjunto de entradas (ver Figura 4.10). Un conjunto de entradas vacío indica que la actividad
72
no requiere datos para iniciar la ejecución. El elemento InputSet hereda los atributos y las
asociaciones de BaseElement.
Un conjunto de salidas (outputSet) es una colección de datos de salidas los cuales
definen salidas producidas por actividades. Un InputOutputSpecification debe tener al menos
un conjunto de salidas y este conjunto puede tener cero o más datos de salida. Un dato de
salida puede asociarse a múltiples conjuntos de salidas, pero siempre debe hacer referencia al
menos a un conjunto de salidas (ver Figura 4.10). Un conjunto de salidas sin elementos,
significa que la actividad no produce datos de salidas. El elemento OutputSet hereda los
atributos y las asociaciones de BaseElement.
Como se observó en el capítulo 2, una asociación de datos es utilizada para mover
datos entre objetos de datos, propiedades, entrada/salidas de actividades, procesos y tareas
globales. Una asociación de datos tiene origen y destino; cuando la asociación de datos es
ejecutada, el dato del origen de la asociación es copiado en el destino. Las asociaciones de
datos son utilizadas en las diferentes etapas del proceso y en el ciclo de vida de una actividad.
La clase DataAssociation es un BaseElement contenido en una actividad o evento.
Estas asociaciones se utilizan para modelar como un dato navega hacia o desde un elemento
itemAware. Un elemento DataAssociation tiene uno o más orígenes y un destino. Éste
elemento puede observarse en la Figura 4.11. En esta misma Figura también se puede
observar como un elemento itemAware puede poseer un ItemDefinition. Tanto el origen
(sourceRef) como el destino (targetRef) deben tener el mismo ItemDefinition o la asociación
de datos (DataAssociation) debe poseer una expresión de transformación el cual transforme el
ItemDefinition origen en el ItemDefinition destino. Si no existe una transformación definida,
el contenido del origen es copiado en el destino. Si existe una transformación, la expresión es
evaluada y el resultado es copiado en el destino.
Figura 4.11: Clase DataAssociation
73
En cualquier caso, los orígenes son utilizados para definir si la asociación de datos
puede ser "ejecutada"; si algún origen no está disponible, la asociación de datos no se podrá
ejecutar, y la actividad o el evento, donde la asociación de datos es definida, debe esperar que
la condición se cumpla.
Las asociaciones de datos siempre se encuentran contenidas dentro de otro elemento
que define cuándo estas asociaciones de datos se van a ejecutar. La Figura 4.11 muestra como
la clase DataAssociation hereda los atributos y asociaciones de BaseElement.
Un elemento DataInputAssociation se utiliza para asociar un elemento itemAware con
un dato de entrada contenido en una actividad. Es decir, un DataInputAssociation asocia un
dato de entrada del proceso con un dato de entrada de la actividad. De esta forma es posible
saber que datos de entrada de un proceso participan en alguna actividad. El elemento
DataInputAssociation hereda los atributos y las asociaciones de la clase DataAssociation (ver
Figura 4.11).
El DataOutputAssociation se utiliza para asociar un dato de salida contenido dentro de
una actividad con cualquier elemento itemAware. El destino de una asociación de datos puede
ser un elemento itemAware. Un DataOutputAssociation asocia un dato de salida de una
actividad con un dato de salida del proceso. De esta forma es posible saber que datos de salida
de un proceso participan en las actividades. El elemento DataOutputAssociation hereda los
atributos y las asociaciones de la clase DataAssociation (ver Figura 4.11).
4.2.7 Extensiones en el metamodelo
Por otro lado, el metamodelo BPMN2 está pensado para ser extendido. Esto permite ampliar
el metamodelo para satisfacer necesidades específicas para dominios particulares. Para esto
BPMN2 proporciona un conjunto de elementos de extensión, los cuales permite añadir
constructores necesarios sin romper el cumplimiento del estándar. De esta manera, permite
construir modelos intercambiables y ejecutables en motores de flujos de trabajo BPMN2 con
las adecuadas extensiones para soportarlos.
Todos los elementos BPMN2 son subclases de BaseElement, es por ello que todos
estos elementos pueden ser extendidos agregando atributos. La extensión en BPMN2 puede
realizarse con cuatro elementos diferentes, tal como muestra Figura 4.12:
el elemento Extension, el cual se une a un atributo ExtensionDefinition y sus
atributos a la definición del modelo BPMN2,
el elemento ExtensionDefinition, el cual define y agrupa atributos adicionales,
el elemento ExtensionAttributeDefinition, el cual define nuevos atributos y
el elemento ExtensionAttributeValue, el cual contiene el valor del atributo.
74
Figura 4.12: Extensiones en BPMN2
4.3 Metamodelo de ESTECO
ESTECO es una empresa pionera en soluciones de optimización numérica, especializada en la
investigación y desarrollo de software de ingeniería para todas las etapas del proceso de
diseño dirigido por simulación. La misma ha desarrollado modeFRONTIER, una plataforma
de integración para la optimización multi-objetivo y multi-disciplinaria. Esta permite la
automatización de procesos de simulación, y facilita la toma de decisiones analítica [2].
El proceso simulado posee una representación gráfica (utilizado por el ingeniero para
modelar el proceso), mientras que el modelo de ejecución asociado está representado en
XML. Éste último es utilizado por un motor con el fin de ejecutar el flujo de trabajo y llevar a
cabo la simulación.
Los flujos de trabajo incluyen nodos de eventos, nodos de tarea para cada actividad y
nodos de datos utilizados para representar los datos de entrada y salida. Los datos pueden
representar datos simples, como enteros, dobles, vectores, matrices o datos más complejos,
como archivos o bases de datos. Las actividades corresponden a la ejecución de simuladores,
scripts y otras aplicaciones en ubicaciones locales o remotas.
El metamodelo de ESTECO expresa cuáles son los elementos válidos de modelado
para construir instancias de flujos de trabajo de ESTECO. La Figura 4.13 muestra un
diagrama de clase con los elementos principales del metamodelo de ESTECO.
75
Figura 4.13: Elementos principales del metamodelo ESTECO
La clase TGeometry es la clase más externa de todos los elementos del metamodelo de
ESTECO. Todos los elementos de ESTECO están contenidos en un TGeometry. La clase
TGeometry posee relaciones hacia los elementos básicos del metamodelo. Cada relación
posee un nombre de rol, lo que significa que la clase TGeometry posee atributos de estas
clases. A continuación se explican los nombres de rol que aparecen en la Figura 4.13:
dataEdge: Este elemento define la conexión entre los datos de entrada y salida
con las tareas,
processEdge: Este elemento define la conexión entre los eventos y las tareas y
la conexión entre las tareas,
outputDataNode: Representa los datos de salida,
inputDataNode: Representa los datos de entrada,
taskNode: Representa las tareas de ESTECO,
startNode Representa el evento de inicio,
exitNode Representa los eventos de fin.
La Figura 4.14 muestra los elementos relacionados a los eventos. Las clases
TStartNode y TExitNode representan los nodos de inicio y de fin respectivamente en un flujo
de trabajo. Estas clases heredan los atributos y asociaciones de TEventNode y ésta a su vez de
TNode. Las clases TEndConnector y TStartConnector permiten a otro elemento del
metamodelo determinar desde y hacia dónde se dirige la ejecución (ver más adelante). TNode
es una clase abstracta de la cual heredan muchos de los principales elementos en el
76
metamodelo de ESTECO.
Figura 4.14: Elementos relacionados a los Eventos
Los elementos del metamodelo poseen conectores los cuales ayudan a determinar con
quienes están relacionados. Estos conectores asisten a los elementos dataEdge y processEdge.
El elemento dataEdge relaciona los datos de entrada y salida con las tareas. El elemento
processEdge relaciona los eventos con las tareas y las tareas entre ellas. La Figura 4.15
muestra estos elementos. Los atributos from y to contienen los identificadores de aquellos
conectores que deben relacionar.
Figura 4.15: Conectores del metamodelo
Como se dijo anteriormente, las tareas y los procesos generalmente necesitan datos
para su ejecución. Además, pueden producir datos o resultados durante la ejecución. Como
puede observarse en la Figura 4.16, las asociaciones que tiene TGeometry poseen los roles de
inputDataNode y outputDataNode. Estos roles hacen referencia a los tipos de datos del
metamodelo de ESTECO. Los datos de entrada y salida son capturados en TInputDataNode y
TOutputDataNode respectivamente. Estos elementos heredan los atributos y asociaciones de
la clase TDataNode, la cual posee el tipo del dato y que a su vez hereda de la clase TNode la
cual posee el identificador y el nombre del dato. El elemento TInputDataNode es un tipo
77
particular de TDataNode el cual se utilizará como entrada de un objeto TGeometry a una
tarea. Este elemento posee uno o más outputDataConnector. Este conector ayuda a
determinar que tareas tendrán como entrada ese dato. El elemento TOutputDataNode es un
tipo particular de TDataNode el cual almacena el dato producido por una tarea contenida en
TGeometry. Este elemento posee dos conectores, outputDataConnector el cual ayuda a
determinar que tareas tendrán como entrada ese dato producido, y el conector
inputDataConnector el cual ayuda a determinar que tarea es la que produjo ese dato.
Figura 4.16: Modelado de Datos
Las tareas, además de llevar un cierto tiempo para ejecutarlas, pueden necesitar
recursos, datos y propiedades específicas dependiendo del dominio. Una tarea que se realiza
dentro de un flujo de trabajo industrial de ESTECO se representa a través de la clase
TTaskNode. Esta clase posee conectores para relacionarse con los datos:
bufferInputDataConnector y bufferOutputDataConnector, y conectores para relacionarse con
las tareas y con los eventos: endConnector y startConnector. Estos conectores asisten a los
78
elementos dataEdge y processEdge como se mencionó anteriormente. En la Figura 4.17
puede observarse en la clase TTaksNode algunos atributos que representan propiedades
propias de ESTECO. La clase TTaksNode hereda los atributos y asociaciones de la clase
TNode.
Figura 4.17: Modelado de Tareas
Como se mencionó anteriormente, los metamodelos son los encargados de definir la
semántica que especifica cómo los elementos del modelo serán instanciados, es decir que los
metamodelos se utilizan para describir distintos tipos de modelos. Las transformaciones
permiten transformar un modelo en otro pero sus reglas son genéricas y están escritas a nivel
de metamodelo. El siguiente capítulo explica cómo están construidas estas reglas y cómo
hacer referencia a los elementos de los metamodelos descriptos en este capítulo.
79
Capítulo 5
Transformaciones
La clave de MDA son los modelos y las transformaciones entre ellos ya sea para refinarlos o
para llegar a código ejecutable. Teniendo en mente este objetivo, la OMG propone el lenguaje
estándar QVT para expresar consultas y definir transformaciones de modelos. BPMN2 ha sido
desarrollado teniendo en cuenta algunas limitaciones y dándole mayor importancia a los
objetos de datos persiguiendo el objetivo de poder interpretar y ejecutar directamente los
modelos. Los flujos de trabajo ingenieriles, comparten muchas características con los
conocidos flujos de trabajo científicos, muy utilizados en la industria hoy en día. Si bien estos
flujos de trabajo son ampliamente utilizados, actualmente no existe ningún estándar para la
definición de los mismos. Con el fin de construir modelos unificados y estandarizados, los
flujos de trabajo ingenieriles de la empresa ESTECO serán transformados al nuevo estándar
de BPMN2 permitiendo además la ejecución de los mismos.
El presente capítulo muestra en primer lugar la arquitectura de la transformación, explicando
los diferentes niveles y los elementos que la componen. Posteriormente se describe cuales son
los elementos transformados en este trabajo y cuales son sus correspondencias. Finalmente se
muestra, de manera detallada, como se realiza la transformación de una parte significativa de
este trabajo de tesis, ilustrando la definición de las reglas (relaciones) escritas en el lenguaje
Relations QVT, junto con la correspondencia entre los elementos de los metamodelos
involucrados en la transformación. Esta transformación fue definida utilizando Medini QVT,
herramienta desarrollada por tecnologías IKV++ con integración de Eclipse [59].
5.1 Arquitectura
Como se explicó en el capítulo 3, la transformación de modelos es considerado el proceso
central de MDA. Este proceso consiste en convertir un modelo en otro basado en una serie de
reglas. Para lograr esto, la OMG ha definido un conjunto específico de capas y
transformaciones. En particular, la OMG identifica tres tipos de modelos los cuales cubren
todo el ciclo de vida de un sistema de software: modelo independiente de la computación
(CIM), modelo independiente de la plataforma (PIM) y modelo específico de la plataforma
(PSM).
80
Como se explicó en el capítulo 3 un CIM es una vista de un sistema desde el punto de
vista de computación independiente, a veces es llamado modelo de dominio o modelo de
negocio. CIM representa un nivel alto en el modelado. Es decir que se puede ocultar mucho o
toda la información sobre el uso de los sistemas automatizados de procesamiento de datos.
Este modelo es independiente de cómo se implementa el sistema. Uno de los objetivos de los
CIM es que cualquiera que sea capaz de comprender las necesidades y los procesos que
actuarán en un sistema pueda comprender un CIM.
Un PIM es una vista de un sistema el cual representa la lógica del sistema y sus
interacciones con el mundo exterior, ocultando los detalles necesarios para una plataforma en
particular [50]. Un PIM representa un modelo sin hacer referencia a ninguna plataforma en la
cual será desarrollada la aplicación, además ignora los sistemas operativos, los lenguajes de
programación, el hardware, etc. Es decir que este modelo debe tener tal nivel de abstracción
que no cambie, sea cual fuere la plataforma elegida para su implementación.
Un PSM es una vista de un sistema desde el punto de vista específico de la plataforma,
es decir, es un modelo del sistema con detalles específicos a la plataforma en la cual será
implementado, es decir que los PSMs tienen que tener en cuenta explícitamente los sistemas
operativos, los lenguajes de programación y las plataformas. Un PSM producido por la
transformación desde un PIM, representa el mismo modelo pero en otro nivel de abstracción.
PSM puede proveer diferentes niveles de detalles, dependiendo su propósito. PSM será una
implementación, si éste proporciona toda la información necesaria para construir un sistema y
ponerlo en funcionamiento, o puede actuar como un PIM que es utilizado para fomentar el
refinamiento para un PSM que puede ser directamente implementado [6]. Se puede decir
entonces que un PSM es un PIM el cual tendrá detalles específicos para ser implementado en
una plataforma determinada. PSM es un modelo de bajo nivel, muy cercano al código.
En este trabajo de tesis se presenta una transformación horizontal, es decir convertir un
modelo de un nivel a otro modelo del mismo nivel, pero ambos basados en modelos de nivel
superior (metamodelos) diferentes.
Las transformaciones QVT describen las relaciones entre metamodelos fuentes y
metamodelos destinos, ambos especificados en MOF [54]. La transformación definida es
aplicada al modelo origen, el cual es una instancia del metamodelo ESTECO, para obtener el
modelo destino, instancia del metamodelo BPMN2. La Figura 5.1 muestra la arquitectura de
transformación de modelos; en ella se ilustra cómo se definen y aplican las transformaciones
que están basadas en la utilización de metamodelos. En el nivel superior se puede observar los
metamodelos utilizados en la definición de la transformación, ESTECO y BPMN2
respectivamente. En el nivel intermedio se encuentran los modelos específicos a los cuales se
les aplicará la transformación, definida anteriormente, para obtener modelos BPMN2. El nivel
inferior representa las instancias de los modelos, los cuales serán ejecutados en el
correspondiente motor del flujo de trabajo.
81
Figura 5.1: Arquitectura de la Transformación
La Figura 5.1 está directamente relacionada con la arquitectura UML. Esta
arquitectura se divide en cuatro capas conceptuales. Un ejemplo que ayuda a explicar los
niveles de modelado se muestra en la Figura 5.2 [14].
Figura 5.2: Ejemplo de la jerarquía de las cuatro capas del metamodelo
Como se dijo anteriormente, el nivel del meta-metamodelado es la base en la jerarquía
de metamodelado. Su responsabilidad principal es definir el lenguaje para la especificación de
un metamodelo. La capa se denomina M3 y MOF es un ejemplo de un meta-metamodelo.
TaskNode
:TaskNode
Calculator
+type: String<<imagen >>/
<<instanciaDe>>
<<instanciaDe>> <<instanciaDe>> <<instanciaDe>> <<instanciaDe>>
<<instanciaDe>> <<instanciaDe>> <<instanciaDe>>
<<clasificador>>
Metamodelo
de ESTECO
Instancia
ESTECO
Instancia
BPMN2
Modelo
ESTECO
Modelo
BPMN2
Metamodelo
de BPMN2
Definición de la Transformación
utilizando QVT
Aplicación de la Transformación
Transformación de las instancias
ejecutables del modelo
82
Dicho lenguaje se define por la OMG con el fin de definir constructores y mecanismos para
describir metamodelos. En general, es conveniente que tanto el meta-metamodelo y el
metamodelo compartan constructores comunes. Sin embargo, cada capa puede ser vista
independientemente de otras capas.
Un metamodelo es una instancia de un meta-metamodelo. Su responsabilidad
principal es definir un lenguaje para especificar modelos. La capa se denomina M2. Ejemplos
que se encuentran en este nivel son UML, además de los metamodelos de BPMN2 y
ESTECO, como se observó en la Figura 5.1. Todos estos están expresados en MOF.
Un modelo es una instancia de un metamodelo. Su responsabilidad principal es definir
los lenguajes que describen los dominios semánticos, es decir, permitir a los usuarios modelar
una amplia variedad de dominios. Esta capa se denomina M1. Los modelos de ESTECO y
BPMN2 caen en este nivel. Los conceptos definidos en M1 especifican la clasificación para
los elementos de M0.
Los elementos de la capa denominada M0 son instancias de un modelo particular, de
un sistema real. Un ejemplo de una instancia de la clase TaskNode es Calculator, ver Figura
5.2.
5.2 Transformación y Relación Funcional
Un proceso es el elemento principal en el modelado de flujos de trabajo de negocio. Un
proceso describe una secuencia o flujo de actividades de una organización con el objetivo de
llevar a cabo un trabajo. En BPMN2 un proceso se representa como un grafo de actividades,
eventos y compuertas, los cuales están relacionados por los flujos de secuencia que definen el
flujo de ejecución.
Como se presentó en el capítulo 4, un proceso está contenido en el elemento
Definitions [4]. Un proceso es instanciado cuando ocurre un evento de inicio. Un evento de
fin indicará donde el proceso terminará, terminando el flujo de ejecución. Las actividades
representan tareas a realizar. Los datos de entrada y de salida están contenidos en un objeto
oiSpecification, los cuales no sólo están definidos en el proceso, sino que también están
definidos en aquellas actividades en las cuales participan.
La Figura 5.3 ilustra la correspondencia entre los elementos de ESTECO y los de
BPMN2. Cada caja corresponde a un elemento XML, y la jerarquía entre los elementos es
representada con la estructura de un árbol.
En la parte de ESTECO puede observarse que el elemento principal es TGeometry.
Éste posee los nodos de inicio y fin, las tareas, los datos de entrada (inputDataNode), los
datos de salida (outputDataNode), los conectores (dataEdge) para conectar los datos con una
tarea y otros conectores (processEdge) para realizar la conexión de los eventos con las tareas
y la conexión entre las tareas. Además puede observarse en la Figura 5.3 que cada elemento
83
de TGeometry posee conectores que asisten a los elementos dataEdge y processEdge.
En la parte de BPMN2 se observa que el elemento principal es definitions y con él el
elemento proceso (process) el cual contiene los eventos de inicio y fin, las tareas, flujos de
secuencia y el objeto ioSpecification el cual contiene los datos de entrada y salida que
participan en el proceso.
En la transformación de las tareas es necesario utilizar en más de una oportunidad el
mecanismo de extensión de BPMN2 para satisfacer las necesidades específicas de ESTECO.
Cada tarea posee un elemento propio de ESTECO (providerKey) el cual es agregado a través
del mecanismo de extensión. Además posee un objeto ioSpecification el cual contiene los
datos que participan en la tarea [4], como se mencionó en el capítulo 4. Estos datos son, datos
de entrada (dataInputs), datos de salida (dataOutputs), conjunto de datos de entrada
(inputSets) y conjunto de datos de salida (outputSets). Cada dato de entrada relacionado a una
tarea del flujo de trabajo de ESTECO, capturado en el objeto inputDataNode, es transformado
en un dato de entrada (dataInput) de BPMN2, junto con elementos propios de ESTECO. En la
Figura 5.3 puede observarse como los dataInput poseen estos elementos para extender el
metamodelo. Además las tareas poseen propiedades específicas dependiendo del tipo de tarea.
Estas propiedades se representan con el elemento properties de BPMN2 junto con elementos
propios de ESTECO. Por último las tareas poseen las asociaciones de datos, estos son:
dataInputAssociation y dataOutputAssociation.
84
Figura 5.3: Correspondencia entre los elementos de ESTECO y los de BPMN2
ESTECO BPMN2
process
ioSpecification
startEvent
Task
ioSpecification
dataInput
extensionValues
default
dataOutput
inputSet
outputSet
endEvent
sequenceFlow
TGeometry
startNode
endConnector
taskNode
startConnector
bufferInputDataConnector
inputDataNode
outputDataNode
outputDataConnector
inputDataConnector
outputDataConnector
dataEdge
endConnector
bufferOutputDataConnector
dataInput
dataOutput
inputSet
outputSet
exitNode
startConnector
definitions
processEdge
extensionValues
providerKey
properties
extensionValues
default
dataInputAssociation
sourceRef
targetRef
dataOutputAssociation
sourceRef
targetRef
85
5.3 Reglas definidas para la transformación
Una transformación especifica un grupo de relaciones que los elementos de los modelos
involucrados deben satisfacer. Como se mencionó en capítulos anteriores una transformación
puede tener cualquier número de parámetros de entrada y salida. Los parámetros de entrada
corresponden a los modelos a los cuales se les aplicará la transformación para generar los
parámetros de salida. Para cada parámetro de salida, una nueva instancia de modelo será
creada y/o modificada de acuerdo al metamodelo al que pertenece dicho modelo destino (en
este trabajo, el metamodelo es BPMN2).
Cada dominio identifica una correspondencia de un conjunto de elementos definidos
llamados patrones.
Una relación en QVT define reglas de transformación, y esa relación implica la
existencia de clases para cada uno de sus dominios. El dominio es un tipo el cual puede ser la
raíz de un patrón. Un dominio implica la existencia de una propiedad del mismo tipo en una
clase. Como se dijo anteriormente, un patrón puede ser visto como un conjunto de variables y
un conjunto de restricciones que los elementos de los modelos deben satisfacer. Además se
vio, que los dominios pueden ser marcados como checkonly y enforce y que las relaciones
pueden contener las cláusulas when y where [48]. Un tipo de modelo es definido por un
metamodelo y un conjunto opcional de expresiones de condición.
Para ilustrar cómo se van transformando los elementos, a continuación se mostrarán
las relaciones correspondientes a un nodo de inicio [13], una tarea [13], flujo de ejecución y
los datos involucrados a la tarea [11] [12]. Las relaciones completas se pueden observar en el
Anexo A.
Las transformaciones comienzan definiendo el nombre de la misma junto con los
modelos candidatos y sus metamodelos respectivamente. En la Figura 5.4 se muestra la
transformación ESTECOToBPMN2, la cual toma como modelo origen un modelo ESTECO,
el cual es una instancia del metamodelo ESTECO, y produce como modelo destino un modelo
BPMN2, el cual será una instancia del metamodelo BPMN2. Tanto el metamodelo de
ESTECO como de BPMN2 se encuentran en formato ecore. Además, se presenta la relación
createProcess, la cual constituye el punto de entrada para comenzar la transformación en
QVT. La finalidad de esta relación es crear la etiqueta Definitions, etiqueta principal en
cualquier modelo BPMN2 la cual contiene la etiqueta Process, e invocar a las otras relaciones
encargadas de completar la transformación para la creación del modelo BPMN2.
86
Figura 5.4: Definición de la transformación
El dominio definido como enforce corresponde al modelo BPMN2, lo cual significa
que este modelo será una instancia del metamodelo BPMN2. La Figura 5.5 muestra parte de
este metamodelo donde pueden observarse los elementos utilizados en la Figura 5.4.
Figura 5.5: Elementos involucrados en la relación createProcess
transformation ESTECOToBPMN2(source : esteco_m, target : bpmn2){
top relation createProcess {
checkonly domain source g:esteco_m::TGeometry{ };
enforce domain target d : bpmn2::Definitions{
rootElements = r : bpmn2::Process{
name = 'EstecoMainProcess',
id = 'EstecoMainProcess',
isExecutable = true,
processType = bpmn2::ProcessType::Private
}
};
…
where {
createSequenceFlowStart2Activity(g, r);
taskNode2taskBPMN2(g, r);
…
}
}
…
}
87
Una vez creado el proceso con sus respectivas etiquetas, la transformación se dirige
hacia la cláusula where para chequear que las relaciones createSequenceFlowStart2Activity y
taskNode2taskBPMN2 se satisfagan. Estas relaciones definen el mapeo entre los elementos
del metamodelo ESTECO y los elementos del metamodelo BPMN2 relacionados con el
evento de inicio y las tareas respectivamente.
La Figura 5.6 muestra la relación createSequenceFlowStart2Activity. Esta relación
define la transformación de un evento de inicio de ESTECO hacia una tarea relacionados a
través de un conector.
Figura 5.6: Relación para transformar un evento de inicio
En esta relación puede observarse como un nodo de inicio (startNode) se transforma
relation createSequenceFlowStart2Activity{
e_id :String;
e_name : String;
id_end_connector: String;
checkonly domain source g : esteco_m::TGeometry{
taskNode = task : esteco_m::TTaskNode {
startConnector = start_connector : esteco_m::TStartConnector {}
},
processEdge = process_edge : esteco_m::TProcessEdge {},
startNode = s:esteco_m::TStartNode {
id = e_id,
name = e_name,
endConnector = e : esteco_m::TEndConnector{
id= id_end_connector
}
}
};
enforce domain target p:bpmn2::Process{
flowElements = f :bpmn2::StartEvent{
id= e_id,
name= e_name },
flowElements = flow : bpmn2::SequenceFlow {
sourceRef = f,
targetRef = task2 : bpmn2::Task {
id = task.id
}
}
};
when {
if (id_end_connector = process_edge.from and start_connector.id = process_edge.to )
then
true else
false
endif;
}
}
88
en un evento de inicio (startEvent). El nodo de inicio posee un conector de fin
(endConnector) el cual ayudará a determinar hacia donde se dirige la ejecución. Un nodo de
tarea (taskNode) posee un conector de inicio (startConnector) el cual también ayudará a
determinar desde donde proviene la ejecución. El nodo processEdge es el encargado de
relacionar el conector de fin (del nodo de inicio) y el conector de inicio (del nodo de tarea).
Ambos conectores asisten al objeto processEdge para generar la conexión entre el nodo de
inicio y el nodo de tarea. En conclusión se puede observar cómo el objeto processEdge
corresponde a un flujo de secuencia de BPMN2.
En la Figura 5.7 se puede ver parte de los metamodelos involucrados en la relación
antes vista.
ESTECO
BPMN2
Figura 5.7: Elementos de los metamodelos involucrados en la relación
createSequenceFlowStart2Activity
De manera similar se genera la transformación del nodo de fin junto con su flujo de
ejecución, ver Anexo A relación: createEndEventSequenceFlowActivity2EndEvent.
Continuando con el análisis de la Figura 5.4, se puede observar que la cláusula where
de esta Figura también posee la relación taskNode2taskBPMN2. Está relación define el mapeo
entre las tareas de ESTECO y las tareas del BPMN2 (ver Figura 5.8).
89
Figura 5.8: Relación para transformar una tarea
En esta relación se puede destacar 3 partes. La primera parte hace referencia al
dominio ESTECO marcado con checkonly. Aquí se muestra el procedimiento para extraer los
valores referidos a las tareas pertenecientes a la instancia del metamodelo ESTECO (modelo
origen) tales como su identificador (id), su nombre (name), una propiedad específica (charset)
y el tipo de la tarea (type). La segunda parte hace referencia al dominio BPMN2 marcado
como enforce. Esto es, si la comprobación falla, se modificará el modelo destino, creando,
borrando o modificando sus elementos para lograr satisfacer la relación. En este caso se
crearán elementos en el modelo BPMN2 (modelo destino). La Figura 5.9 muestra los
elementos de los metamodelos involucrados en esta relación.
relation taskNode2taskBPMN2 {
id_task, name_task, charset_task, type_task : String;
valueType:String;
checkonly domain source g:esteco_m::TGeometry {
taskNode = t :esteco_m::TTaskNode{
id= id_task,
name= name_task,
charset= charset_task,
type= type_task
}
};
enforce domain target p:bpmn2::Process {
flowElements = f :bpmn2::Task {
name = name_task,
id = id_task,
extensionValues= extension : esteco::DocumentRoot {
providerKey = prp :esteco::TRequiredValue{
value = valueType
}
}
}
};
where{
valueType = if (type_task = 'it.esteco.integration.calculator.workflow.CalculatorNode') then
'Calculator'
…
createIOSpecificationTask(g, f, id_task);
createSequenceFlow(g,id_task, p);
-- si es un Calculator se generan las propiedades de Calculator
if (valueType='Calculator')then
propertyCalculator(g, name_task, charset_task, f, id_task)
…
}
}
90
ESTECO
BPMN2
Figura 5.9: Elementos de los metamodelos involucrados en la relación taskNode2taskBPMN2
Note además que en la relación aparece un atributo extensionValues (en el modelo
destino), este atributo pertenece a la clase BaseElement del metamodelo BPMN2, el cual está
definido por el tipo ExtensionAttributeValue.
Para comprender las extensiones tratadas durante el proceso de transformación, es
necesario hacer referencia a la definición de los tipos en el metamodelo ESTECO. Parte de
esta definición es presentada en la Figura 5.10, donde la clase DocumentRoot, elemento
principal en un modelo ecore, hereda los atributos y las asociaciones de la clase
ExtensionAttributeValue, clase perteneciente a la definición de BPMN2, como puede verse en
la Figura 5.9. Esto es necesario para agregar nuevos atributos que no pertenecen a BPMN2,
por ejemplo se añade al modelo destino el atribute providerKey perteneciente a la clase
DocumentRoot y del tipo TRequiredValue, clase de ESTECO la cual posee un atributo value.
Figura 5.10: Elementos del metamodelo ESTECO para extender las tareas
Como se dijo al principio de este capítulo, la transformación de tareas implica también
la transformación y/o generación de otros elementos los cuales están involucrados en ellas.
91
ESTECO posee distintos tipos de tareas, cada una de estas posee propiedades
específicas. Es decir, dependiendo del tipo de la tarea deben crearse propiedades particulares.
La distinción de estos tipos pueden observarse en la clausula where, tercera parte de la
relación. A través de una condición se le asignará a una variable el tipo de tarea, en este caso
un Calculator, para luego generar las propiedades específicas de él. Además se observan dos
relaciones createIOSpecificationTask, createSequenceFlow. La relación
createIOSpecificationTask es la encargada de definir el mapeo entre los elementos del
metamodelo ESTECO y los elementos del metamodelo BPMN2 relacionados con los datos de
entrada y salida. La relación createSequenceFlow se encargará del proceso de transformación
relacionado a los flujos de ejecución y las tareas, en particular esta relación genera un flujo de
secuencia entre la tarea que se está transformando y la tarea anteriormente transformada.
La cláusula where finaliza con una sentencia de condición la cual chequea el tipo de
tarea. Dependiendo de ésta se chequeará una relación encargada de generar las propiedades
específicas de esa tarea (propertyCalculator).
A continuación se explicarán las relaciones createSequenceFlow y propertyCalculator,
respectivamente, finalizando con la relación createIOSpecificationTask.
Los elementos de un modelo deben estar conectados para seguir la ejecución. Como
los flujos de trabajo de ESTECO pertenecen a un único pool, la conexión entre los elementos
BPMN2 se realiza a través de flujos de secuencia. La relación createSequenceFlow define el
mapeo entre un flujo de ejecución de ESTECO y uno de BPMN2 entre actividades, ya que el
flujo de secuencia entre un evento y una actividad es tratada en la relación que mapea los
eventos de inicio y fin respectivamente. La Figura 5.11 muestra la relación antes mencionada.
92
Figura 5.11: Relación para transformar un flujo de secuencia
En el dominio marcado como checkonly (modelo origen) se puede observar cómo se
obtiene el identificador de la tarea (id) y a través del atributo endConnector se obtiene un
identificador el cual ayudará para saber desde donde proviene la ejecución. El elemento
processEdge pertenece a la clase TProcessEdge la cual hereda los atributos de la clase TEdge
(ver Figura 5.12), esta clase posee dos atributos: from y to, estos atributos poseen los
identificadores los cuales son el origen y destino de un flujo de ejecución.
Si se observa en la relación de la Figura 5.8 la relación createSequenceFlow posee tres
parámetros, el primero hace referencia al elemento del tipo TGeometry (g), el segundo hace
referencia al identificador de la tarea a la cual se está transformando y el tercero hace
referencia al elemento del tipo Process (p).
En la relación de la Figura 5.11 se observa un dominio primitivo String, éste es
necesario para “capturar” el identificador que aparece como segundo parámetro en la relación
y de este modo, no “perder” el identificador de la tarea que se está transformando.
En el dominio marcado como enforce se puede observar cómo se creará el flujo de
secuencia en el modelo destino. Como se ve en la Figura 5.12 la clase SequenceFlow posee
relation createSequenceFlow{
id_task_node, id_connector:String;
checkonly domain source g:esteco_m::TGeometry{
taskNode = task_node :esteco_m::TTaskNode{
id = id_task_node,
endConnector = end_connector : esteco_m::TEndConnector {
id= id_connector
}
},
processEdge = process_edge : esteco_m::TProcessEdge{}
};
primitive domain id_task:String;
enforce domain target p :bpmn2::Process {
flowElements = task : bpmn2::Task{
id=id_task
},
flowElements = flow1 : bpmn2::SequenceFlow {
sourceRef = task2 : bpmn2::Task {
id= id_task_node
},
targetRef = task
}
};
when {
if (id_connector = process_edge.from and process_edge.to = id_task + '_0' ) then
true else
false
endif;
}
}
93
dos atributos sourceRef y targetRef, estos atributos contendrán el origen y destino del flujo de
secuencia. De este modo se observa en la relación como se le asigna al atributo sourceRef una
tarea y al atributo targetRef la tarea transformada en la relación antes vista. En la cláusula
when se observa una sentencia condicional la cual controla que las tareas estén conectadas.
ESTECO
BPMN2
Figura 5.12: Elementos de los metamodelos involucrados en la relación createSequenceFlow
De esta manera, se puede observar cómo se construyó una relación la cual transforma
un flujo de ejecución ESTECO a un flujo de secuencia BPMN2 entre tareas.
Como se mencionó anteriormente, la cláusula where de la Figura 5.8 tiene una
condición que controla el tipo de la tarea. Dependiendo de esta condición deberán ser creadas
las propiedades para cada tipo de tarea. La Figura 5.13 muestra la relación propertyCalculator
encargada de crear las propiedades de la tarea Calculator. Esta Figura muestra algunas de las
propiedades. La relación completa puede verse en el Anexo A.
Todos los dominios, a excepción del marcado como enforce, previos a la cláusula
where, son utilizados para mantener datos necesarios para crear las propiedades.
94
Figura 5.13: Relación para crear propiedades de la tarea Calculator
Por una cuestión de simplicidad se explicarán sólo dos de las propiedades. Las otras
relaciones se encuentran en el Anexo A.
Todas las propiedades de los tipos de las tareas de ESTECO poseen un tipo particular
y valores los cuales, o vienen proporcionados por la configuración a la hora de generar el flujo
de trabajo o son valores asignados por defecto. En la Figura 5.14, se puede observar cómo se
generan dos de las propiedades de Calculator. En cada relación se puede observar como el
segmento que enmarca el dominio enforce agrega una propiedad a la tarea, en este caso
charset y KeepAlive respectivamente. Aquí se puede ver como se agrega el nombre de la
propiedad junto con el tipo al cual hace referencia la misma (itemSubjectRef), en el caso de la
propiedad charset hace referencia a un String, y en el caso KeepAlive hace referencia a un
Boolean. El estándar de BPMN2 no permite asignarles valores a las propiedades, para
soportar esta carencia se utiliza el mecanismo de extensión que éste provee. Para esto es
necesario hacer referencia a la definición de los tipos en el metamodelo ESTECO. Parte de
esta definición es presentada en la Figura 5.15, donde la clase DocumentRoot, posee una
relación de generalización con la clase ExtensionAttributeValue, como se vio anteriormente,
esta clase pertenece a la definición de BPMN2. En las relaciones puede observarse como se
generan los atributos para asignarle el valor a la propiedad a través del atributo value, este
atributo pertenece a la clase TSimpleValue la cual es parte de la clase TDefault que a su vez es
parte de la clase DocumentRoot (ver Figura 5.15).
relation propertyCalculator{
checkonly domain source g : esteco_m::TGeometry{};
primitive domain name_task:String;
primitive domain charset_task:String;
enforce domain target t :bpmn2::Task { };
primitive domain id_task:String;
where {
propertyCharset(g, charset_task, t);
propertyKeepAlive(g,t);
…
}
}
95
Figura 5.14: Relaciones para crear la propiedad Charset y KeepAlive
ESTECO
BPMN2
Figura 5.15: Elementos de los metamodelos involucrados en las relaciones propertyCharset y
propertyKeepAlive
relation propertyCharset {
checkonly domain source g : esteco_m::TGeometry{};
primitive domain charset_task:String;
enforce domain target t :bpmn2::Task {
properties = charset : bpmn2::Property {
name = 'charset',
itemSubjectRef = item : bpmn2::ItemDefinition{
id = 'StringItemDefinition' },
extensionValues = extension : esteco::DocumentRoot{
default = default : esteco::TDefault {
simpleValue = simple_value : esteco::TSimpleValue {
value = 'calculator.charset.' + charset_task }
} }
}
};
}
relation propertyKeepAlive {
checkonly domain source g : esteco_m::TGeometry{};
enforce domain target t :bpmn2::Task {
properties = keepAlive : bpmn2::Property {
name = 'keepAlive',
itemSubjectRef = item : bpmn2::ItemDefinition{
id = 'BooleanItemDefinition' },
extensionValues = extension : esteco::DocumentRoot{
default = default : esteco::TDefault {
simpleValue = simple_value : esteco::TSimpleValue {
value = 'false' }
} }
}
};
}
96
De modo similar se generan todas las otras propiedades de Calculator.
De esta manera se mostró como se transforma una tarea de ESTECO a BPMN2, junto
con sus propiedades y el flujo de ejecución entre una tarea y otra.
Para finalizar la transformación de una tarea a otra es necesario definir el mapeo
relacionado con los datos de entrada y salida involucrados en la misma. La Figura 5.8 muestra
la relación createIOSpecificationTask, encargada del mapeo, la cual será ejecutada tras la
aplicación de la relación taskNode2taskBPMN2 al igual que createSequenceFlow.
Las transformaciones de los datos de ESTECO a BPMN2 no son directas. Un dato de
entrada del modelo ESTECO no es solamente un elemento de entrada en el modelo BPMN2,
ya que en BPMN2 los datos de entrada (DataInputs) son capturados en InputSets y ambos son
añadidos en un elemento ioSpecification. Además cabe aclarar que los datos de entrada de
ESTECO poseen valores los cuales o han sido asignados cuando se construyó el flujo de
trabajo o son valores por defecto. Para poder soportar estos valores, es necesario utilizar el
mecanismo de extensión que provee BPMN2.
Los datos de salida se manejan de modo similar que los de entrada, estos
(DataOutputs) son capturados en OutputSets y ambos son añadidos al mismo elemento
ioSpecification que los datos de entrada. En consecuencia, en la transformación es necesario
generar un objeto ioSpecification para agregar los DataInputs, DataOutputs, InputSets y
OutputSets respectivamente. Antes de transformar los datos es necesario generar el elemento
ioSpecification. En la Figura 5.16 puede observarse cómo en el dominio marcado como
enforce se crea este elemento. Luego, en la cláusula where, se realiza la invocación de las
relaciones para transformar los datos de entrada y salida (DataInput, DataOutput) además de
crear los objetos en los cuales estarán contenidos éstos.
Figura 5.16: Relación para crear el elemento ioSpecification
Como se vio en el capítulo 4 un InputSets es una colección de elementos DataInputs
que juntos definen el conjunto válido de datos de entradas asociado a un elemento
ioSpecification. Un ioSpecification debe tener definido al menos un elemento InputSets. Un
relation createIOSpecificationTask {
checkonly domain source g:esteco_m::TGeometry { };
enforce domain target t:bpmn2::Task {
ioSpecification= ioSpecif : bpmn2::InputOutputSpecification {}
};
primitive domain id_task:String;
where {
getDataInputTask(g,ioSpecif, id_task);
createInputSetsTask(ioSpecif,ioSpecif);
getDataOutputTask(g, ioSpecif, id_task);
createOutputSetsTask(ioSpecif, ioSpecif);
}
}
97
OutputSets es una colección de elementos DataOutputs que juntos pueden producir salidas
desde una actividad. Un elemento ioSpecification debe tener también al menos un elemento
OutputSets [4] (ver Figura 5.17).
Figura 5.17: Elementos del metamodelo BPMN2 involucrados en la transformación de
datos
Para poder crear un objeto de la clase InputSets es necesario obtener los datos de
entrada del modelo ESTECO, para luego generar los DataInputs y añadirlos al objeto
InputSets. La relación utilizada para obtener los datos de entrada del modelo de ESTECO y
generar los DataInputs en BPMN2 es presentada en la Figura 5.18.
98
Figura 5.18: Relación para transformar los datos de entrada
Cada dato de entrada de ESTECO debe ser transformado en un dato de entrada de
BPMN2. Como se dijo con anterioridad esta transformación no es directa; el código QVT
presentado anteriormente, muestra el procedimiento por el cual el identificador (id), nombre
(name), valor (value) y conectores son obtenidos de la instancia del metamodelo ESTECO
(modelo origen) para ser generados en una instancia del metamodelo BPMN2 (modelo
destino). El nodo dataEdge es el encargado de relacionar el dato (conector de salida del dato)
con la tarea (conector de entrada para el dato). Los conectores outputDataConnector y
bufferInputDataConnector respectivamente asisten al elemento dataEdge para reflejar la
conexión. Cabe aclarar que esta relación sólo transforma los datos que tienen conexión con la
relation getDataInputTask{
id_input, name_input : String;
value_input : Real;
checkonly domain source g:esteco_m::TGeometry{
taskNode = t:esteco_m::TTaskNode{
bufferInputDataConnector = buffer_input : esteco_m::TBufferInputDataConnector {}
},
inputDataNode = input : esteco_m::TInputDataNode {
id = id_input,
name = name_input,
value = value_input,
outputDataConnector = output_data : esteco_m::TOutputDataConnector{ }
},
dataEdge = data_edge : esteco_m::TDataEdge {}
};
primitive domain id_task:String;
enforce domain target ioSpecif : bpmn2::InputOutputSpecification {
dataInputs = data_input : bpmn2::DataInput {
id= id_input + '_T' + id_task,
name = name_input,
itemSubjectRef = item : bpmn2::ItemDefinition {
id = 'DoubleItemDefinition'
},
extensionValues = extension : esteco::DocumentRoot{
default = default : esteco::TDefault {
simpleValue = simple_value : esteco::TSimpleValue {
value = value_input
}
}
}
}
};
when {
if (data_edge.from = output_data.id)and (data_edge.to = buffer_input.id ) and (id_task=t.id)
then
true else
false
endif;
}
}
99
tarea que está siendo transformada. Aquellos datos que no estén conectados con esta tarea son
descartados. De esta manera, cada tarea contendrá sólo los datos involucrados en ella.
La Figura 5.19 muestra los elementos del metamodelo de ESTECO relacionados a los
datos.
Figura 5.19: Elementos del metamodelo ESTECO involucrados en la transformación
de datos
Una vez obtenida toda la información de los datos que provienen del modelo origen,
se comienza con la creación de los datos en el modelo destino. En el dominio marcado con
enforce, de la Figura 5.18, puede observarse como, por un lado se crea el dato de entrada
(dataInput) y con él su identificador (id), nombre (name) y el tipo al cual hará referencia
(itemSubjectRef). Por otro lado, se observa la utilización del mecanismo de extensión de
BPMN2 para soportar la asignación de valores, por defecto o no, de los datos. Para soportar
esta carencia es necesario hacer referencia, una vez más, a la definición de los tipos en el
metamodelo ESTECO como se vio anteriormente en la Figura 5.15, donde la clase
DocumentRoot posee una relación de generalización con la clase ExtensionAttributeValue.
Entonces el valor del dato será guardado en el atributo value el cual es un atributo de la clase
TSimpleValue la cual es parte de la clase TDefault que a su vez es parte de la clase
100
DocumentRoot. La relación concluye con la cláusula when la cual restringe que la relación
será satisfecha cuando el dato que se está transformando tiene una conexión directa con la
tarea. De esta manera se van transformando cada dato de entrada, es decir que por cada dato
de entrada que posea el modelo origen esta relación se ejecutará.
Una vez generados todos los datos de entrada, la transformación continúa en la
relación createIOSpecificationTask, ver Figura 5.16, donde es invocada la relación
createInputSetsTask, la cual será la encargada de generar el elemento InputSets que contendrá
los datos de entrada generados recientemente. La Figura 5.20 muestra esta relación. Aquí se
puede observar como en el dominio enforce se genera el elemento InputSets y de qué manera
se le añaden los datos de entrada (dataInputs), antes transformados, al atributo dataInputRefs
del metamodelo BPMN2 como se mostró en la Figura 5.17.
Figura 5.20: Relación para generar el elemento InputSets y añadirle los DataInputs
Una vez transformados los datos de entrada y generado el elemento InputSets la
transformación continua transformando los datos de salida, relacionados a esta tarea,
invocando a la relación getDataOutputTask en la relación de la Figura 5.16.
La Figura 5.21 muestra la relación getDataOutputTask, ésta es muy similar a la
relación getDataInputTask. Ambas difieren en los tipos de conectores que aparecen en la
relación y además en que los datos de salida no necesitan utilizar el mecanismo de extensión
de BPMN2.
relation createInputSetsTask {
checkonly domain target ioSpecif: bpmn2::InputOutputSpecification {
};
enforce domain target ioSpecif : bpmn2::InputOutputSpecification {
inputSets = input_set :bpmn2::InputSet{
dataInputRefs= ioSpecif.dataInputs
}
};
}
101
Figura 5.21: Relación para transformar los datos de salida
Una vez generados los datos de salida, el control regresa a la relación
createIOSpecificationTask para invocar a la relación createOutputSetsTask. Esta relación es la
encargada de generar el elemento OutputSets el cual contendrá los datos recientemente
transformados (ver Figura 5.22).
Figura 5.22: Relación para generar el elemento OutputSets y añadirle los DataOutputs
relation getDataOutputTask{
id_output, name_output : String;
checkonly domain source g:esteco_m::TGeometry{
taskNode = t:esteco_m::TTaskNode{
bufferOutputDataConnector = buffer_output : esteco_m::TBufferOutputDataConnector {}
},
outputDataNode = output : esteco_m::TOutputDataNode {
id = id_output,
name = name_output,
inputDataConnector = input_data : esteco_m::TInputDataConnector{ }
},
dataEdge = data_edge : esteco_m::TDataEdge {}
};
primitive domain id_task:String;
enforce domain target ioSpecif : bpmn2::InputOutputSpecification {
dataOutputs = data_output : bpmn2::DataOutput {
id= id_output + '_T' + id_task,
name = name_output,
itemSubjectRef = item : bpmn2::ItemDefinition {
id = 'DoubleItemDefinition'
}
}
};
when {
if (data_edge.from = buffer_output.id) and (data_edge.to = input_data.id ) and (id_task=t.id)
then
true else
false
endif;
}
}
relation createOutputSetsTask{
checkonly domain target ioSpecif: bpmn2::InputOutputSpecification{
};
enforce domain target ioSpecif : bpmn2::InputOutputSpecification{
outputSets = output_set :bpmn2::OutputSet{
dataOutputRefs= ioSpecif.dataOutputs
}
};
}
102
De esta manera finaliza la transformación relacionada a las tareas junto con los datos
que participan en ella.
El siguiente capítulo muestra la aplicación de la transformación en un caso de estudio
real de la empresa ESTECO.
103
Capítulo 6
Caso de Estudio
En este capítulo se presenta un ejemplo de una transformación de un flujo de trabajo de
ESTECO a BPMN2. Este flujo ingenieril presenta la optimización de un motor de combustión
interna de cuatro cilindros. Él mismo persigue el objetivo de reducir las emisiones de NOx
(óxido de nitrógeno), manteniendo el consumo de combustible tan bajo como sea posible. La
transformación utilizada ha sido descripta en el capítulo 5.
6.1 Introducción
La empresa ESTECO es pionera en soluciones de optimización numérica. La misma está
especializada en la investigación y desarrollo de software de ingeniería para todas las etapas
del proceso de diseño dirigido por simulación. Además tiene una amplia experiencia en el
ámbito de flujos de trabajo de ingeniería aplicada en el contexto industrial. ESTECO ha
desarrollado su propio modelador y motor de flujo de trabajo llamado modeFRONTIER.
modeFRONTIER [2] es un software de propósito general de integración de procesos y
optimización de diseño. Su plataforma de optimización es multi-disciplinar y multi-objetivo.
A través de algoritmos e integración agiliza el proceso de ingeniería. En numerosas industrias,
modeFRONTIER se ha convertido en una herramienta esencial para mejorar la comprensión
de los factores costo / rendimiento y reducir el tiempo de desarrollo de los productos. La
Figura 6.16 muestra el editor del flujo de trabajo de modeFRONTIER. Todas las categorías de
nodos están en la paleta Nodos y los flujos de trabajo se crean de manera inmediata. El
Registro de Lógica (Logic Log) y el árbol de trabajo (Workflow Tree), que muestra la
estructura, ofrecen a los diseñadores crear un flujo de trabajo intuitivo y personalizado.
6 La Figura es cortesía de ESTECO SpA
104
Figura 6.1: Entorno modeFRONTIER
6.2 Un caso de estudio
La Figura 6.2 muestra un ejemplo de optimización de un motor de combustión interna de
cuatro cilindros el cual busca reducir las emisiones de NOx (óxidos de nitrógeno)
manteniendo el consumo de combustible tan bajo como sea posible [60]. Estos dos objetivos
están en conflicto, ya que una única solución no puede ser considerada óptima para ambos
objetivos al mismo tiempo.
Figura 6.2: Flujo de trabajo para optimizar un motor de combustión
105
Los nodos DOE y DOE Sequence representan el nodo de inicio del flujo de trabajo.
Estos dos nodos son inseparables, por lo que están presentes siempre en todo flujo de trabajo,
identificando de manera univoca el punto de inicio de la ejecución. El nodo GTSuite
representa la interacción con el simulador, encargándose de la interacción entre la herramienta
de optimización y el simulador. Este nodo pasa los valores de los parámetros de configuración
(datos de entrada) y guarda los resultados producidos por el simulador en los datos de salida.
En el flujo de trabajo se consideran cuatro variables de entrada: el tiempo de aspiración
(INTCAM), tiempo de descarga (EXHCAM), punto de encendido (TH50) y la longitud del
conducto de aspiración (INTRUNLENGHT), y dos variables de salida que son producidas por
el simulador: el nivel de emisiones de NOx (NOx) y el consumo de combustible (BSFC). El
nodo End representa donde proceso termina.
Como se mencionó en el capítulo 4, un proceso de ESTECO posee una representación
gráfica, pero el modelo de ejecución está representado en formato XML. Sus elementos
fueron descriptos en el mencionado capítulo.
El código completo del ejemplo puede observarse en el Anexo B, y el código generado
tras la aplicación de la transformación puede observarse en el Anexo C. Como se mencionó en
el capítulo anterior la transformación construida en este trabajo se encuentra en el Anexo A.
La Figura 6.3 muestra parte del código del ejemplo, el cual representa el nodo inicio,
la relación aplicada que transforma este nodo en un evento de inicio, y además muestra el
código BPMN2 que ella produjo, luego de haber generado la etiqueta process.
Figura 6.3: Transformación del nodo de inicio
Modelo origen
Modelo destino
relation createSequenceFlowStart2Activity{
e_id :String;
e_name : String;
id_end_connector: String;
checkonly domain source g : esteco_m::TGeometry{
startNode = s:esteco_m::TStartNode {
id = e_id,
name = e_name,
endConnector = e : esteco_m::TEndConnector{
id= id_end_connector
}
}
};
enforce domain target p:bpmn2::Process{
flowElements = f :bpmn2::StartEvent{
id= e_id,
name= e_name
},
};
}
<esteco_m:TGeometry>
<startNode id="_12" name="Start12">
<endConnector id="_12_2"/>
</startNode>
…
</esteco_m:TGeometry>
<flowElements
xsi:type="bpmn2:StartEvent"
id="_12" name="Start12"/>
106
En la Figura 6.3 se puede observar que existe una correspondencia entre el dominio
checkonly y los datos del modelo origen. Además se puede observar cómo se genera el
correspondiente código BPMN2 a través del dominio enforce. De manera similar se
transforma el nodo de fin.
Como se mencionó en el capítulo 5, en la relación para transformar las tareas se
pueden distinguir 3 partes. La Figura 6.4 muestra la primera y segunda parte de esta relación.
En ella se puede observar cómo se utilizan las extensiones para soportar especificaciones
propias de ESTECO.
Figura 6.4: Primera parte de la transformación de tareas
La Figura 6.5 muestra una porción de la tercera parte de la relación la cual es la
encargada de obtener el tipo de la tarea para luego generar las propiedades específicas de
ellas. Además, en esta parte se encuentran las invocaciones para generar el objeto
ioSpecification, los DataAssociation y para generar un flujo de secuencia entre tareas en caso
de que existan.
Modelo origen
Modelo destino
relation taskNode2taskBPMN2 {
id_task, name_task, charset_task, type_task,
model_task : String;
valueType:String;
checkonly domain source g:esteco_m::TGeometry{
taskNode = t :esteco_m::TTaskNode{
id= id_task,
name= name_task,
charset= charset_task,
type= type_task,
model = model_task
}
};
enforce domain target p:bpmn2::Process {
flowElements = f :bpmn2::Task {
name = name_task,
id = id_task,
extensionValues= extension :
esteco::DocumentRoot {
providerKey = prp :esteco::TRequiredValue{
value = valueType
}
}
}
};
…
}
<taskNode id="17" name="GTSuite17"
charset="US-ASCII" relative="false"
termination="DOS" timeout="0"
type=
"it.esteco.integration.gtsuite.workflow.GTSuiteNode"
model=
"D:\users\Alberto\GT_POWER_CLUSTERING\... ">
<startConnector id="_17_0"/>
<endConnector id="_17_2"/>
<bufferInputDataConnector id="_17_1"/>
<bufferOutputDataConnector id="_17_3"/>
</taskNode>
<flowElements xsi:type="bpmn2:Task" id="17"
name="GTSuite17" … >
<extensionValues
xsi:type="esteco:DocumentRoot">
<providerKey value="GTSuiteNode"/>
</extensionValues>
107
Figura 6.5: Segunda parte de la relación que transforma las tareas
La Figura 6.6 muestra la última porción de la tercera parte de esta relación la cual es la
encargada de invocar las relaciones que generan las propiedades específicas de cada tarea, en
este caso se realizará la invocación de la relación propertyGTSuiteNode.
Figura 6.6: Tercera parte de la relación que transforma las tareas
Como puede verse en la Figura 6.7, la relación propertyGTSuiteNode contiene las
invocaciones a las relaciones encargadas de generar cada propiedad.
…
if (valueType='Calculator')then
propertyCalculator(g, name_task, charset_task, f, id_task)
else
if (valueType='GTSuiteNode')then
propertyGTSuiteNode(g, name_task, charset_task, f, id_task, model_task)
else
propertySimulationX(g, name_task,id_task, f)
endif
endif;
}
where{
valueType = if (type_task =
'it.esteco.integration.calculator.workflow.CalculatorNode') then
'Calculator'
else
if (type_task =
'it.esteco.integration.gtsuite.workflow.GTSuiteNode') then
'GTSuiteNode'
else
'SimulationX'
endif
endif;
createIOSpecificationTask(g, f, id_task);
createDataInputAssociation(g,id_task,f);
createDataOutputAssociation(g,id_task, f);
createSequenceFlow(g,id_task, p);
…
108
Figura 6.7: Relación propertyGTSuiteNode
Como se puede notar en la Figura 6.7 una de las propiedades es Model. La generación
de esta propiedad en el modelo destino puede observarse en la Figura 6.8. En ella puede verse,
una vez más, cómo se hace uso del mecanismo de extensión necesario para soportar flujos de
trabajo de ESTECO. De manera similar se generan las propiedades Charset y Timeout.
Figura 6.8: Generación de la propiedad Model
En la Figura 6.7 también se hacen presentes las invocaciones de las relaciones
propertyGTSuiteParameterModelInput y propertyGTSuiteParameterModelOutput. Estas
relaciones hacen referencias a las propiedades ParameterModel que poseen todas las tareas de
ESTECO. Estas propiedades hacen referencia a datos de entrada y salida respectivamente. A
continuación se muestra la Figura 6.9 la cual presenta la propiedad
relation propertyGTSuiteNode{
checkonly domain source g : esteco_m::TGeometry{};
primitive domain name_task:String;
primitive domain charset_task:String;
enforce domain target t :bpmn2::Task { };
primitive domain id_task:String;
primitive domain model_task:String;
where {
propertyCharset(g, charset_task, t);
propertyTimeout(g,t);
propertyModel(g,model_task,t);
propertyGTSuiteParameterModelInput(g,id_task,t);
propertyGTSuiteParameterModelOutput(g,id_task,t);
}
}
Modelo destino
relation propertyModel {
checkonly domain source g :
esteco_m::TGeometry{};
primitive domain model_task:String;
enforce domain target t :bpmn2::Task {
properties = charset : bpmn2::Property {
name = 'model',
itemSubjectRef = item:bpmn2::ItemDefinition{
id = 'StringItemDefinition' },
extensionValues = extension :
esteco::DocumentRoot{
default = default : esteco::TDefault {
simpleValue = simple_value :
esteco::TSimpleValue {
value = model_task }
}
}
}
};
}
<properties id="_9RvjuCqbEeOyA8UU1qDtUQ"
name="model"
itemSubjectRef="StringItemDefinition" >
<extensionValues xsi:type="esteco:DocumentRoot">
<default>
<simpleValue
value="D:\users\Alberto\GT_POWER_CLUSTERING\..."/
>
</default>
</extensionValues>
</properties>
109
propertyGTSuiteParameterModelInput y muestra lo que ella genera. Cabe aclarar que esta
relación debe obtener cada dato de entrada del modelo origen.
Figura 6.9: Generación de la propiedad propertyGTSuiteParameterModelInput
relation propertyGTSuiteParameterModelInput{
id_input, name_input : String;
value_input : Real;
checkonly domain source g:esteco_m::TGeometry{
taskNode = t:esteco_m::TTaskNode{
bufferInputDataConnector = buffer_input :
esteco_m::TBufferInputDataConnector {}
},
inputDataNode = input : esteco_m::TInputDataNode {
id = id_input,
name = name_input,
value = value_input,
outputDataConnector = output_data :
esteco_m::TOutputDataConnector{ }
},
dataEdge = data_edge : esteco_m::TDataEdge {}
};
primitive domain id_task:String;
enforce domain target task : bpmn2::Task {
properties = parameter : bpmn2::Property {
name= name_input,
itemSubjectRef = item : bpmn2::ItemDefinition {
id= 'tGTSuiteParameterModel' },
extensionValues = extension:esteco::DocumentRoot{
default = default : esteco::TDefault {
complexValue = complex :
esteco::TComplexValue {
tgSuiteParameterModel = parameterModel :
esteco::TParameterModel {
datatype = 'xsd.double',
name = name_input }
}
},
dataInterfaceRef = dataInter :
esteco::TRequiredValue {
value = id_input + '_T' + id_task }
}
}
};
when { if (data_edge.from = output_data.id) and
(data_edge.to = buffer_input.id ) and
(id_task=t.id) then
true else
false
endif;
}
}
<properties id="_u6h7kCthEeOotIiqjt66Mg"
name="INTCAM"
itemSubjectRef="tGTSuiteParameterModel">
<extensionValues
xsi:type="esteco:DocumentRoot">
<default>
<complexValue>
<tgSuiteParameterModel
datatype="xsd.double"
name="INTCAM"/>
</complexValue>
</default>
<dataInterfaceRef value="_1_T17"/>
</extensionValues>
</properties>
Modelo origen
Modelo destino
<inputDataNode id="_1" name="INTCAM"
type="it.esteco.procint.workflow.InputNode"
expression="" kind="VARIABLE"
value="0.0">
<outputDataConnector id="_1_2"/>
</inputDataNode>
<dataEdge from="_1_2" to="_17_1"/>
110
De manera similar se genera la propiedad propertyGTSuiteParameterModelOutput,
relacionada a los datos de salida.
A continuación se muestra como se transforman los datos de entrada del caso de
estudio. Para una mejor comprensión se mostrará cómo se transforman los datos de entrada
que participan en una tarea. Se debe recordar que los datos de entrada y salida que participan
en una tarea están contenidos dentro de una etiqueta ioSpecification perteneciente a la tarea.
Además, los datos de entrada y salida que participan en todo el proceso están contenidas en
otra etiqueta ioSpecification contenida dentro de la etiqueta process, ver Anexo C.
La relación encargada de generar el objeto ioSpecification posee las invocaciones para
transformar los datos de entrada y salida. Además, invoca las relaciones para generar los
conjuntos de entradas y conjuntos de salida que contienen ambos datos, ver Anexo A relación
createIOSpecificationTask. La Figura 6.10 muestra la transformación de los datos de entrada,
luego de haber generado el elemento ioSpecification.
111
Figura 6.10: Transformación de los datos de entrada
En el modelo origen puede observarse que además del código sobre los datos de
Modelo origen
Modelo destino
relation getDataInputTask{
id_input, name_input : String;
value_input : Real;
checkonly domain source g:esteco_m::TGeometry{
taskNode = t:esteco_m::TTaskNode{
bufferInputDataConnector = buffer_input :
esteco_m::TBufferInputDataConnector {}
},
inputDataNode = input : esteco_m::TInputDataNode {
id = id_input,
name = name_input,
value = value_input,
outputDataConnector = output_data :
esteco_m::TOutputDataConnector{ }
},
dataEdge = data_edge : esteco_m::TDataEdge {}
};
primitive domain id_task:String;
enforce domain target ioSpecif :
bpmn2::InputOutputSpecification {
dataInputs = data_input : bpmn2::DataInput {
id= id_input + '_T' + id_task,
name = name_input,
itemSubjectRef = item : bpmn2::ItemDefinition {
id = 'DoubleItemDefinition'
},
extensionValues = extension : esteco::DocumentRoot{
default = default : esteco::TDefault {
simpleValue = simple_value : esteco::TSimpleValue{
value = '0'
}
}
}
}
};
when {
if (data_edge.from = output_data.id)and (data_edge.to =
buffer_input.id ) and (id_task=t.id) then
true else
false
endif;
}
}
<inputDataNode id="_1" name="INTCAM"
type="it.esteco.procint.workflow.InputNode"
expression="" kind="VARIABLE" value="0.0">
<outputDataConnector id="_1_2"/>
</inputDataNode>
<dataEdge from="_1_2" to="_17_1"/>
<ioSpecification
id="_9Q-utSqbEeOyA8UU1qDtUQ">
<dataInputs id="_1_T17"
name="INTCAM"
itemSubjectRef="DoubleItemDefinition" >
<extensionValues
xsi:type="esteco:DocumentRoot">
<default>
<simpleValue value="0"/>
</default>
</extensionValues>
</dataInputs>
…
</ioSpecification>
112
entrada se encuentra el elemento dataEdge, este elemento asiste en la clausula when para
determinar que el dato que se está transformando participe de la tarea que también está
transformándose. De manera similar se transforman los datos de salida, sólo que ellos no
poseen extensiones. La Figura 6.11 muestra esta transformación.
Figura 6.11: Transformación de los datos de salida
En este capítulo se presentó parte de la aplicación de la transformación, construida en
este trabajo, convirtiendo un flujo de trabajo de la empresa ESTECO modelado con su editor
modeFRONTIER al estándar BPMN2.
Modelo origen
Modelo destino
relation getDataOutputTask{
id_output, name_output : String;
checkonly domain source g:esteco_m::TGeometry{
taskNode = t:esteco_m::TTaskNode{
bufferOutputDataConnector = buffer_output :
esteco_m::TBufferOutputDataConnector {}
},
outputDataNode = output:esteco_m::TOutputDataNode{
id = id_output,
name = name_output,
inputDataConnector = input_data :
esteco_m::TInputDataConnector{ }
},
dataEdge = data_edge : esteco_m::TDataEdge {}
};
primitive domain id_task:String;
enforce domain target ioSpecif :
bpmn2::InputOutputSpecification{
dataOutputs = data_output : bpmn2::DataOutput {
id= id_output + '_T' + id_task,
name = name_output,
itemSubjectRef = item : bpmn2::ItemDefinition {
id = 'DoubleItemDefinition'
}
}
};
when {
if (data_edge.from = buffer_output.id) and (data_edge.to=
input_data.id ) and (id_task=t.id) then
true else
false
endif;
}
}
<outputDataNode id="_9" name="NOX"
type="it.esteco.procint.workflow.OutputNode">
<inputDataConnector id="_9_0"/>
<outputDataConnector id="_9_2"/>
</outputDataNode>
<dataEdge from="_17_3" to="_9_0"/>
<ioSpecification
id="_9Q-utSqbEeOyA8UU1qDtUQ">
<dataOutputs id="_9_T17"
name="NOX"
itemSubjectRef="DoubleItemDefinition"/>
…
</ioSpecification>
113
Capítulo 7
Conclusiones y Trabajos Futuros
En este capítulo se presentan las conclusiones y contribuciones de este trabajo de tesis.
Además se describen los aspectos que constituyen el punto de partida para el desarrollo de
trabajos futuros.
7.1 Conclusiones
La automatización de procesos de negocio es un componente clave para el crecimiento de las
organizaciones. Existen muchos estándares en el ámbito de procesos de negocio pero no son
directamente aplicables al campo de la ingeniería, ya que éstos poseen requerimientos
específicos. BPMN es el estándar ampliamente utilizado para el modelado de procesos de
negocio y ha sido recientemente mejorado permitiendo extender su metamodelo facilitando su
aplicación a dominios particulares.
Por otra parte, la Arquitectura Dirigida por Modelos [6] [7], implementación de la
OMG para la Ingeniería Dirigida por Modelos [8] [9], propone un proceso de desarrollo de
software en el cual la clave son los modelos y las transformaciones entre ellos. Teniendo en
mente este objetivo, la OMG propone QVT, un lenguaje estándar para expresar consultas y
definir transformaciones de modelos.
Por otro lado, en el contexto de la ingeniería, es habitual requerir la ejecución de
muchas actividades paralelas con interdependencias complejas. Existe un gran número de
formatos gráficos y de ejecución que se encuentran en uso hoy en día. Aunque los flujos de
trabajo científicos o ingenieriles se han utilizado con éxito desde hace muchos años, la
mayoría de las herramientas que se utilizan para definirlos y ejecutarlos no están basados en
tecnologías estándar.
El trabajo desarrollado ha mostrado como es posible modelar un flujo de trabajo
ingenieril con BPMN2, notación para el modelado de procesos de negocio, gracias a su
mecanismo de extensión. Es importante destacar que la utilización de estándares en los
sectores industriales garantiza portabilidad entre las herramientas que soportan el estándar
BPMN2. Además cabe mencionar, que el uso de estándares para flujos de trabajo científicos o
114
ingenieriles facilita la colaboración entre científicos y diseñadores industriales, mejorando la
interacción entre los diferentes campos. De esta manera se logra proporcionar un vocabulario
común [3], reutilización de modelos que sigan con el estándar e independizar los modelos
construidos de los motores de ejecución.
Para llevar a cabo el objetivo había que considerar que existe una gran cantidad de
flujos de trabajo ingenieriles ya diseñados y utilizados actualmente por la industria y que no
podían descartarse. Con el fin de proporcionar soporte para estos flujos de trabajo se ha
construido una transformación utilizando una tecnología basada en QVT. Esta transformación
permite transformar los flujos de trabajo ingenieriles definidos en el formato propietario de
ESTECO al estándar de procesos de negocio BPMN2.
Las reglas de transformación, especificadas en este trabajo, han sido validadas
experimentalmente aplicándolas a un caso de estudio real industrial de la empresa
especializada en optimización multi-objetivo ESTECO.
Como contribución, se puede mencionar que este enfoque proporcionará un incentivo
adicional para que las empresas abandonen los modeladores propietarios y comiencen a
utilizar tecnologías estándar que vienen de la mano de los procesos de negocio.
Si bien la empresa ESTECO está actualmente trabajando para soportar el estándar, se
ha hecho necesario llevar a cabo una transformación desde el metamodelo de ESTECO al
metamodelo BPMN2. Esta transformación permite la conversión de muchos flujos de trabajo
industriales de ESTECO a BPMN2 consintiendo su ejecución en motores BPMN2, con las
adecuadas extensiones para soportar las propiedades específicas de los flujos de trabajo de
ESTECO.
Otra ventaja que se puede destacar es que es posible reducir la brecha entre la teoría de
la notación de procesos de negocio para los flujos de trabajo y las tecnologías de información
para aplicaciones ingenieriles.
7.2 Trabajos Futuros
Teniendo en cuenta que QVT permite definir transformaciones genéricas las cuales
pueden ser bidireccionales, se espera extender este trabajo realizando una transformación de
BPMN2 a ESTECO logrando así, la ejecución de procesos de negocio en el motor del
modelador modeFRONTIER.
Además se hace posible profundizar la investigación y estudiar la posibilidad de
aplicar el concepto de coreografías del estándar BPMN2 en el ámbito de procesos
industriales.
Estudiar la posibilidad de transformar un modelo BPEL (Business Process Execution
Language) o XPDL y lograr la ejecución en la plataforma de integración modeFRONTIER.
115
El trabajo realizado deja la puerta abierta para continuarlo y lograr la transformación
de los nodos restantes que posee el modelador modeFRONTIER, tales como: nodos de
conexión, nodos CAD, otros nodos de aplicación, etc., y generar los correspondientes
modelos ingenieriles en BPMN2.
116
Anexo A
Reglas de Transformación transformation ESTECOToBPMN2(source : esteco_m, target : bpmn2){
key ItemDefinition {id};
key DataInput{id};
key DataOutput{id};
key Task{id};
key EndEvent{id};
top relation GeometryToDefinitions {
checkonly domain source g:esteco_m::TGeometry {};
enforce domain target d: bpmn2::Definitions{
imports = i :bpmn2::Import {
importType = 'http://www.w3.org/2001/XMLSchema',
location = 'calculatorParameterModel.xsd',
namespace = 'http://www.esteco.com'
},
imports = i2 :bpmn2::Import {
importType = 'http://www.w3.org/2001/XMLSchema',
location = 'esteco.xsd',
namespace = 'http://www.esteco.com'
},
rootElements = double : bpmn2::ItemDefinition{
id= 'DoubleItemDefinition',
structureRef = 'xsd:double'
},
rootElements = string : bpmn2::ItemDefinition{
id= 'StringItemDefinition',
structureRef = 'xsd:string'
},
rootElements = anyType : bpmn2::ItemDefinition{
id= 'AnyTypeItemDefinition',
structureRef = 'xsd:any'
},
rootElements = tCalculator : bpmn2::ItemDefinition{
id= 'tCalculatorParameterModel',
structureRef = 'esteco:tCalculatorParameterModel'
},
rootElements = tTGSuite : bpmn2::ItemDefinition{
id= 'tGTSuiteParameterModel',
structureRef = 'esteco:tTGSuiteParameterModel'
},
rootElements = float : bpmn2::ItemDefinition{
id= 'FloatItemDefinition',
structureRef = 'xsd:float'
},
rootElements = doubleArray : bpmn2::ItemDefinition{
117
id= 'DoubleArrayItemDefinition',
structureRef = 'esteco:array'
},
rootElements = doubleMatrix : bpmn2::ItemDefinition{
id= 'DoubleMatrixItemDefinition',
structureRef = 'esteco:matrix'
},
rootElements = int : bpmn2::ItemDefinition{
id= 'IntItemDefinition',
structureRef = 'xsd:int'
},
rootElements = boolean : bpmn2::ItemDefinition{
id= 'BooleanItemDefinition',
structureRef = 'xsd:boolean'
},
rootElements = anyUri : bpmn2::ItemDefinition{
id= 'AnyURIItemDefinition',
structureRef = 'xsd:anyURI'
}
};
}
top relation createProcess {
checkonly domain source g:esteco_m::TGeometry{ };
enforce domain target d : bpmn2::Definitions{
rootElements = r : bpmn2::Process{
name = 'EstecoMainProcess',
id = 'EstecoMainProcess',
isExecutable = true,
processType = bpmn2::ProcessType::Private
}
};
when {
GeometryToDefinitions(g,d);
}
where {
createSequenceFlowStart2Activity(g, r);
createEndEventSequenceFlowActivity2EndEvent(g,r);
createIOSpecification(g,r);
taskNode2taskBPMN2(g, r);
}
}
relation createSequenceFlowStart2Activity{
e_id :String;
e_name : String;
id_end_connector: String;
checkonly domain source g : esteco_m::TGeometry{
taskNode = task : esteco_m::TTaskNode {
startConnector = start_connector : esteco_m::TStartConnector {}
118
},
processEdge = process_edge : esteco_m::TProcessEdge {},
startNode = s:esteco_m::TStartNode {
id = e_id,
name = e_name,
endConnector = e : esteco_m::TEndConnector{
id= id_end_connector
}
}
};
enforce domain target p:bpmn2::Process{
flowElements = f :bpmn2::StartEvent{
id= e_id,
name= e_name
},
flowElements = flow : bpmn2::SequenceFlow {
sourceRef = f,
targetRef = task2 : bpmn2::Task {
id = task.id
}
}
};
when {
if (id_end_connector = process_edge.from and start_connector.id = process_edge.to ) then
true
else
false
endif;
}
}
relation createEndEventSequenceFlowActivity2EndEvent {
checkonly domain source g: esteco_m::TGeometry {
exitNode = exit : esteco_m::TExitNode {
startConnector = start_connector : esteco_m::TStartConnector {}
},
taskNode = t : esteco_m::TTaskNode {
endConnector = end_connector : esteco_m::TEndConnector {}
},
processEdge = process_edge : esteco_m::TProcessEdge {}
};
enforce domain target p: bpmn2::Process {
flowElements = f :bpmn2::EndEvent{
id= exit.id,
name = exit.name
},
flowElements = sequence_flow : bpmn2::SequenceFlow{
sourceRef = task : bpmn2::Task{
119
id= t.id
},
targetRef = end_event : bpmn2::EndEvent{
id= exit.id
}
}
};
when {
if (end_connector.id = process_edge.from and start_connector.id = process_edge.to) then
true
else
false
endif;
}
}
relation createIOSpecification {
checkonly domain source g:esteco_m::TGeometry {};
enforce domain target p:bpmn2::Process {
ioSpecification = ioSpecif : bpmn2::InputOutputSpecification {}
};
where {
inputDataNode2dataInput(g,ioSpecif);
createInputSets(ioSpecif,ioSpecif);
outputDataNode2dataOutput(g,ioSpecif);
createOutputSets(ioSpecif,ioSpecif);
}
}
relation inputDataNode2dataInput{
expression_input, id_input, kind_input, name_input, type_input: String;
id_output_data_connector : String;
value_input:Real;
checkonly domain source g:esteco_m::TGeometry {
inputDataNode = input:esteco_m::TInputDataNode{
expression= expression_input,
id = id_input,
kind = kind_input,
name = name_input,
type = type_input,
value = value_input,
outputDataConnector = output_data : esteco_m::TOutputDataConnector {
id = id_output_data_connector
}
}
};
enforce domain target ioSpecif:bpmn2::InputOutputSpecification {
dataInputs = data_input : bpmn2::DataInput {
120
id= id_input,
name = name_input,
itemSubjectRef = item : bpmn2::ItemDefinition {
id = 'DoubleItemDefinition'
}
}
};
}
relation createInputSets{
checkonly domain target ioSpecif: bpmn2::InputOutputSpecification{ };
enforce domain target ioSpecif : bpmn2::InputOutputSpecification{
inputSets = input_set :bpmn2::InputSet{
dataInputRefs= ioSpecif.dataInputs
}
};
}
relation outputDataNode2dataOutput{
id_output, name_output, type_output: String;
id_input_data_connector, id_output_data_connector : String;
checkonly domain source g:esteco_m::TGeometry {
outputDataNode = output: esteco_m::TOutputDataNode{
id = id_output,
name = name_output,
type = type_output,
inputDataConnector= input_data : esteco_m::TInputDataConnector{
id= id_input_data_connector
},
outputDataConnector = output_data : esteco_m::TOutputDataConnector {
id = id_output_data_connector
}
}
};
enforce domain target ioSpecif:bpmn2::InputOutputSpecification {
dataOutputs = data_output : bpmn2::DataOutput {
id= id_output,
name = name_output,
itemSubjectRef = item : bpmn2::ItemDefinition {
id = 'DoubleItemDefinition'
}
}
};
}
relation createOutputSets{
checkonly domain target ioSpecif: bpmn2::InputOutputSpecification{ };
121
enforce domain target ioSpecif : bpmn2::InputOutputSpecification{
outputSets = output_set :bpmn2::OutputSet{
dataOutputRefs= ioSpecif.dataOutputs
}
};
}
relation taskNode2taskBPMN2 {
id_task, name_task, charset_task, type_task, model_task : String;
valueType:String;
checkonly domain source g:esteco_m::TGeometry {
taskNode = t :esteco_m::TTaskNode{
id= id_task,
name= name_task,
charset= charset_task,
type= type_task,
model = model_task
}
};
enforce domain target p:bpmn2::Process {
flowElements = f :bpmn2::Task {
name = name_task,
id = id_task,
extensionValues= extension : esteco::DocumentRoot {
providerKey = prp :esteco::TRequiredValue{
value = valueType
}
}
}
};
where{
valueType = if (type_task = 'it.esteco.integration.calculator.workflow.CalculatorNode') then
'Calculator'
else
if (type_task = 'it.esteco.integration.gtsuite.workflow.GTSuiteNode') then
'GTSuiteNode'
else
'SimulationX'
endif
endif;
createIOSpecificationTask(g, f, id_task);
createDataInputAssociation(g,id_task,f);
createDataOutputAssociation(g,id_task, f);
createSequenceFlow(g,id_task, p);
-- si es un Calculator genero las propiedades de Calculator
if (valueType='Calculator')then
122
propertyCalculator(g, name_task, charset_task, f, id_task)
else
if (valueType='GTSuiteNode')then
propertyGTSuiteNode(g, name_task, charset_task, f, id_task, model_task)
else
propertySimulationX(g, name_task,id_task, f)
endif
endif;
}
}
relation createSequenceFlow{
id_task_node, id_connector:String;
checkonly domain source g:esteco_m::TGeometry{
taskNode = task_node :esteco_m::TTaskNode{
id = id_task_node,
endConnector = end_connector : esteco_m::TEndConnector {
id= id_connector
}
},
processEdge = process_edge : esteco_m::TProcessEdge{}
};
primitive domain id_task:String;
enforce domain target p :bpmn2::Process {
flowElements = task : bpmn2::Task{
id=id_task
},
flowElements = flow1 : bpmn2::SequenceFlow {
sourceRef = task2 : bpmn2::Task {
id= id_task_node
},
targetRef = task
}
};
when {
if (id_connector = process_edge.from and process_edge.to = id_task + '_0' ) then
true
else
false
endif;
}
}
relation createDataInputAssociation{
id_input: String;
checkonly domain source g:esteco_m::TGeometry{
taskNode = t:esteco_m::TTaskNode{
bufferInputDataConnector = buffer_input_connector : esteco_m::TBufferInputDataConnector {}
},
123
inputDataNode = input : esteco_m::TInputDataNode {
id = id_input,
outputDataConnector = output_data_connector : esteco_m::TOutputDataConnector{ }
},
dataEdge = data_edge : esteco_m::TDataEdge {}
};
primitive domain id_task : String;
enforce domain target task : bpmn2::Task {
dataInputAssociations = data_input_association : bpmn2::DataInputAssociation {
sourceRef = data_input : bpmn2::DataInput{
id= id_input
},
targetRef = data_input2 : bpmn2::DataInput{
id= id_input + '_T' + id_task
}
}
};
when {
if (data_edge.from = output_data_connector.id)and (data_edge.to = buffer_input_connector.id )
and (id_task=t.id) then
true
else
false
endif;
}
}
relation createDataOutputAssociation{
id_output, name_output : String;
checkonly domain source g:esteco_m::TGeometry{
taskNode = t:esteco_m::TTaskNode{
bufferOutputDataConnector = buffer_output_connector : esteco_m::TBufferOutputDataConnector {}
},
outputDataNode = output : esteco_m::TOutputDataNode {
id = id_output,
name = name_output,
inputDataConnector = input_data_connector : esteco_m::TInputDataConnector{ }
},
dataEdge = data_edge : esteco_m::TDataEdge {}
};
primitive domain id_task:String;
enforce domain target task : bpmn2::Task {
dataOutputAssociations = data_output_association : bpmn2::DataOutputAssociation {
sourceRef = data_output : bpmn2::DataOutput {
id = id_output + '_T' + id_task },
targetRef = data_output2 : bpmn2::DataOutput {
id = id_output
}
124
}
};
when {
if (data_edge.from = buffer_output_connector.id) and (data_edge.to = input_data_connector.id )
and (id_task=t.id) then
true
else
false
endif;
}
}
relation createIOSpecificationTask {
checkonly domain source g:esteco_m::TGeometry {};
enforce domain target t:bpmn2::Task {
ioSpecification = ioSpecif : bpmn2::InputOutputSpecification {}
};
primitive domain id_task:String;
where {
getDataInputTask(g,id_task,ioSpecif);
createInputSetsTask(ioSpecif,ioSpecif);
getDataOutputTask(g,id_task,ioSpecif);
createOutputSetsTask(ioSpecif, ioSpecif);
}
}
relation createInputSetsTask{
checkonly domain target ioSpecif: bpmn2::InputOutputSpecification{ };
enforce domain target ioSpecif : bpmn2::InputOutputSpecification{
inputSets = input_set :bpmn2::InputSet{
dataInputRefs= ioSpecif.dataInputs
}
};
}
relation createOutputSetsTask{
checkonly domain target ioSpecif: bpmn2::InputOutputSpecification{ };
enforce domain target ioSpecif : bpmn2::InputOutputSpecification{
outputSets = output_set :bpmn2::OutputSet{
dataOutputRefs= ioSpecif.dataOutputs
}
};
}
relation getDataInputTask{
125
id_input, name_input : String;
value_input : Real;
checkonly domain source g:esteco_m::TGeometry{
taskNode = t:esteco_m::TTaskNode{
bufferInputDataConnector = buffer_input : esteco_m::TBufferInputDataConnector {}
},
inputDataNode = input : esteco_m::TInputDataNode {
id = id_input,
name = name_input,
value = value_input,
outputDataConnector = output_data : esteco_m::TOutputDataConnector{ }
},
dataEdge = data_edge : esteco_m::TDataEdge {}
};
primitive domain id_task:String;
enforce domain target ioSpecif : bpmn2::InputOutputSpecification {
dataInputs = data_input : bpmn2::DataInput {
id= id_input + '_T' + id_task,
name = name_input,
itemSubjectRef = item : bpmn2::ItemDefinition {
id = 'DoubleItemDefinition'
},
extensionValues = extension : esteco::DocumentRoot{
default = default : esteco::TDefault {
simpleValue = simple_value : esteco::TSimpleValue {
value = '0'
}
}
}
}
};
when {
if (data_edge.from = output_data.id)and (data_edge.to = buffer_input.id ) and (id_task=t.id) then
true
else
false
endif;
}
}
relation getDataOutputTask{
id_output, name_output : String;
checkonly domain source g:esteco_m::TGeometry{
taskNode = t:esteco_m::TTaskNode{
bufferOutputDataConnector = buffer_output : esteco_m::TBufferOutputDataConnector {}
},
outputDataNode = output : esteco_m::TOutputDataNode {
126
id = id_output,
name = name_output,
inputDataConnector = input_data : esteco_m::TInputDataConnector{ }
},
dataEdge = data_edge : esteco_m::TDataEdge {}
};
primitive domain id_task:String;
enforce domain target ioSpecif : bpmn2::InputOutputSpecification {
dataOutputs = data_output : bpmn2::DataOutput {
id= id_output + '_T' + id_task,
name = name_output,
itemSubjectRef = item : bpmn2::ItemDefinition {
id = 'DoubleItemDefinition'
}
}
};
when {
if (data_edge.from = buffer_output.id) and (data_edge.to = input_data.id ) and (id_task=t.id) then
true
else
false
endif;
}
}
relation propertyCalculator{
checkonly domain source g : esteco_m::TGeometry{};
primitive domain name_task:String;
primitive domain charset_task:String;
enforce domain target t :bpmn2::Task { };
primitive domain id_task:String;
where {
propertyCharset(g, charset_task, t);
propertyFormula(g,name_task, t);
propertyTimeout(g,t);
propertyKeepAlive(g,t);
propertyUseGrid(g,t);
propertyVerbose(g,t);
propertyLabel(g,name_task, t);
propertyDescription(g,t);
propertyCalculatorParameterModelInput(g,id_task,t);
propertyCalculatorParameterModelOutput(g,id_task,t);
}
}
--Relaciones Para construir los Parameters Models
relation propertyCalculatorParameterModelOutput{
id_output, name_output : String;
127
checkonly domain source g:esteco_m::TGeometry{
taskNode = t:esteco_m::TTaskNode{
bufferOutputDataConnector = buffer_output : esteco_m::TBufferOutputDataConnector {}
},
outputDataNode = output : esteco_m::TOutputDataNode {
id = id_output,
name = name_output,
inputDataConnector = input_data : esteco_m::TInputDataConnector{ }
},
dataEdge = data_edge : esteco_m::TDataEdge {}
};
primitive domain id_task:String;
enforce domain target task : bpmn2::Task {
properties = parameter : bpmn2::Property {
name= name_output,
itemSubjectRef = item : bpmn2::ItemDefinition {
id= 'tCalculatorParameterModel'
},
extensionValues = extension:esteco::DocumentRoot{
default = default : esteco::TDefault {
complexValue = complex : esteco::TComplexValue {
calculatorParameterModel = parameterModel : esteco::TParameterModel {
datatype = 'xsd.double',
name = name_output
}
}
},
dataInterfaceRef = dataInter : esteco::TRequiredValue {
value = id_output + '_T' + id_task
}
}
}
};
when {
if (data_edge.from = buffer_output.id) and (data_edge.to = input_data.id ) and (id_task=t.id) then
true
else
false
endif;
}
}
relation propertyCalculatorParameterModelInput{
id_input, name_input : String;
value_input : Real;
checkonly domain source g:esteco_m::TGeometry{
taskNode = t:esteco_m::TTaskNode{
bufferInputDataConnector = buffer_input : esteco_m::TBufferInputDataConnector {}
128
},
inputDataNode = input : esteco_m::TInputDataNode {
id = id_input,
name = name_input,
value = value_input,
outputDataConnector = output_data : esteco_m::TOutputDataConnector{ }
},
dataEdge = data_edge : esteco_m::TDataEdge {}
};
primitive domain id_task:String;
enforce domain target task : bpmn2::Task {
properties = parameter : bpmn2::Property {
name= name_input,
itemSubjectRef = item : bpmn2::ItemDefinition {
id= 'tCalculatorParameterModel'
},
extensionValues = extension:esteco::DocumentRoot{
default = default : esteco::TDefault {
complexValue = complex : esteco::TComplexValue {
calculatorParameterModel = parameterModel : esteco::TParameterModel {
datatype = 'xsd.double',
name = name_input
}
}
},
dataInterfaceRef = dataInter : esteco::TRequiredValue {
value = id_input + '_T' + id_task
}
}
}
};
when {
if (data_edge.from = output_data.id)and (data_edge.to = buffer_input.id ) and (id_task=t.id) then
true
else
false
endif;
}
}
-- Fin Relaciones para Parameter Models del Calculator
relation propertySimulationX{
checkonly domain source g : esteco_m::TGeometry{};
primitive domain name_task:String;
primitive domain id_task:String;
enforce domain target t :bpmn2::Task { };
where {
propertyTimeout(g,t);
propertyKeepAlive(g,t);
129
propertyUseGrid(g,t);
propertyVerbose(g,t);
propertyLabel(g,name_task, t);
propertyDescription(g,t);
propertySimulationXParameterModelOutput(g,id_task,t);
propertySimulationXParameterModelInput(g,id_task,t);
}
}
relation propertySimulationXParameterModelOutput{
id_output, name_output : String;
checkonly domain source g:esteco_m::TGeometry{
taskNode = t:esteco_m::TTaskNode{
bufferOutputDataConnector = buffer_output : esteco_m::TBufferOutputDataConnector {}
},
outputDataNode = output : esteco_m::TOutputDataNode {
id = id_output,
name = name_output,
inputDataConnector = input_data : esteco_m::TInputDataConnector{ }
},
dataEdge = data_edge : esteco_m::TDataEdge {}
};
primitive domain id_task:String;
enforce domain target task : bpmn2::Task {
properties = parameter : bpmn2::Property {
name= name_output,
itemSubjectRef = item : bpmn2::ItemDefinition {
id= 'tSimulationXParameterModel'
},
extensionValues = extension:esteco::DocumentRoot{
default = default : esteco::TDefault {
complexValue = complex : esteco::TComplexValue {
simulationXParameterModel = parameterModel : esteco::TParameterModel {
datatype = 'xsd.double',
name = name_output
}
}
},
dataInterfaceRef = dataInter : esteco::TRequiredValue {
value = id_output + '_T' + id_task
}
}
}
};
when {
if (data_edge.from = buffer_output.id) and (data_edge.to = input_data.id ) and (id_task=t.id) then
true
else
false
130
endif;
}
}
relation propertySimulationXParameterModelInput{
id_input, name_input : String;
value_input : Real;
checkonly domain source g:esteco_m::TGeometry{
taskNode = t:esteco_m::TTaskNode{
bufferInputDataConnector = buffer_input : esteco_m::TBufferInputDataConnector {}
},
inputDataNode = input : esteco_m::TInputDataNode {
id = id_input,
name = name_input,
value = value_input,
outputDataConnector = output_data : esteco_m::TOutputDataConnector{ }
},
dataEdge = data_edge : esteco_m::TDataEdge {}
};
primitive domain id_task:String;
enforce domain target task : bpmn2::Task {
properties = parameter : bpmn2::Property {
name= name_input,
itemSubjectRef = item : bpmn2::ItemDefinition {
id= 'tSimulationXParameterModel'
},
extensionValues = extension:esteco::DocumentRoot{
default = default : esteco::TDefault {
complexValue = complex : esteco::TComplexValue {
simulationXParameterModel = parameterModel : esteco::TParameterModel {
datatype = 'xsd.double',
name = name_input
}
}
},
dataInterfaceRef = dataInter : esteco::TRequiredValue {
value = id_input + '_T' + id_task
}
}
}
};
when {
if (data_edge.from = output_data.id)and (data_edge.to = buffer_input.id ) and (id_task=t.id) then
true
else
false
endif;
}
}
131
relation propertyGTSuiteNode{
checkonly domain source g : esteco_m::TGeometry{};
primitive domain name_task:String;
primitive domain charset_task:String;
enforce domain target t :bpmn2::Task { };
primitive domain id_task:String;
primitive domain model_task:String;
where {
propertyCharset(g, charset_task, t);
propertyTimeout(g,t);
propertyModel(g,model_task,t);
propertyGTSuiteParameterModelInput(g,id_task,t);
propertyGTSuiteParameterModelOutput(g,id_task,t);
}
}
relation propertyModel {
checkonly domain source g : esteco_m::TGeometry{};
primitive domain model_task:String;
enforce domain target t :bpmn2::Task {
properties = charset : bpmn2::Property {
-- el id lo genera solo
name = 'model',
itemSubjectRef = item : bpmn2::ItemDefinition{
id = 'StringItemDefinition'
},
extensionValues = extension : esteco::DocumentRoot{
default = default : esteco::TDefault {
simpleValue = simple_value : esteco::TSimpleValue {
value = model_task
}
}
}
}
};
}
relation propertyGTSuiteParameterModelOutput{
id_output, name_output : String;
checkonly domain source g:esteco_m::TGeometry{
taskNode = t:esteco_m::TTaskNode{
bufferOutputDataConnector = buffer_output : esteco_m::TBufferOutputDataConnector {}
},
outputDataNode = output : esteco_m::TOutputDataNode {
id = id_output,
name = name_output,
inputDataConnector = input_data : esteco_m::TInputDataConnector{ }
132
},
dataEdge = data_edge : esteco_m::TDataEdge {}
};
primitive domain id_task:String;
enforce domain target task : bpmn2::Task {
properties = parameter : bpmn2::Property {
name= name_output,
itemSubjectRef = item : bpmn2::ItemDefinition {
id= 'tGTSuiteParameterModel'
},
extensionValues = extension:esteco::DocumentRoot{
default = default : esteco::TDefault {
complexValue = complex : esteco::TComplexValue {
tgSuiteParameterModel = parameterModel : esteco::TParameterModel {
datatype = 'xsd.double',
name = name_output
}
}
},
dataInterfaceRef = dataInter : esteco::TRequiredValue {
value = id_output + '_T' + id_task
}
}
}
};
when {
if (data_edge.from = buffer_output.id) and (data_edge.to = input_data.id ) and (id_task=t.id) then
true
else
false
endif;
}
}
relation propertyGTSuiteParameterModelInput{
id_input, name_input : String;
value_input : Real;
checkonly domain source g:esteco_m::TGeometry{
taskNode = t:esteco_m::TTaskNode{
bufferInputDataConnector = buffer_input : esteco_m::TBufferInputDataConnector {}
},
inputDataNode = input : esteco_m::TInputDataNode {
id = id_input,
name = name_input,
value = value_input,
outputDataConnector = output_data : esteco_m::TOutputDataConnector{ }
},
dataEdge = data_edge : esteco_m::TDataEdge {}
};
primitive domain id_task:String;
133
enforce domain target task : bpmn2::Task {
properties = parameter : bpmn2::Property {
name= name_input,
itemSubjectRef = item : bpmn2::ItemDefinition {
id= 'tGTSuiteParameterModel'
},
extensionValues = extension:esteco::DocumentRoot{
default = default : esteco::TDefault {
complexValue = complex : esteco::TComplexValue {
tgSuiteParameterModel = parameterModel : esteco::TParameterModel {
datatype = 'xsd.double',
name = name_input
}
}
},
dataInterfaceRef = dataInter : esteco::TRequiredValue {
value = id_input + '_T' + id_task
}
}
}
};
when {
if (data_edge.from = output_data.id)and (data_edge.to = buffer_input.id ) and (id_task=t.id) then
true
else
false
endif;
}
}
relation propertyCharset {
checkonly domain source g : esteco_m::TGeometry{};
primitive domain charset_task:String;
enforce domain target t :bpmn2::Task {
properties = charset : bpmn2::Property {
-- el id lo genera solo
name = 'charset',
itemSubjectRef = item : bpmn2::ItemDefinition{
id = 'StringItemDefinition'
},
extensionValues = extension : esteco::DocumentRoot{
default = default : esteco::TDefault {
simpleValue = simple_value : esteco::TSimpleValue {
value = 'calculator.charset.' + charset_task
}
}
}
}
};
134
}
relation propertyFormula {
checkonly domain source g : esteco_m::TGeometry{};
primitive domain name_task:String;
enforce domain target t :bpmn2::Task {
properties = formula : bpmn2::Property {
-- el id lo genera solo
name = 'formula',
itemSubjectRef = item : bpmn2::ItemDefinition{
id = 'AnyURIItemDefinition'
},
extensionValues = extension : esteco::DocumentRoot{
default = default : esteco::TDefault {
simpleValue = simple_value : esteco::TSimpleValue {
value = name_task + '/javaScript.js'
}
}
}
}
};
}
relation propertyTimeout {
checkonly domain source g : esteco_m::TGeometry{};
enforce domain target t :bpmn2::Task {
properties = timeout : bpmn2::Property {
-- el id lo genera solo
name = 'timeout',
itemSubjectRef = item : bpmn2::ItemDefinition{
id = 'IntItemDefinition'
},
extensionValues = extension : esteco::DocumentRoot{
default = default : esteco::TDefault {
simpleValue = simple_value : esteco::TSimpleValue {
value = '0'
}
}
}
}
};
}
relation propertyKeepAlive {
checkonly domain source g : esteco_m::TGeometry{};
enforce domain target t :bpmn2::Task {
properties = keepAlive : bpmn2::Property {
-- el id lo genera solo
name = 'keepAlive',
itemSubjectRef = item : bpmn2::ItemDefinition{
id = 'BooleanItemDefinition'
},
135
extensionValues = extension : esteco::DocumentRoot{
default = default : esteco::TDefault {
simpleValue = simple_value : esteco::TSimpleValue {
value = 'false'
}
}
}
}
};
}
relation propertyUseGrid {
checkonly domain source g : esteco_m::TGeometry{};
enforce domain target t :bpmn2::Task {
properties = useGrid : bpmn2::Property {
-- el id lo genera solo
name = 'useGrid',
itemSubjectRef = item : bpmn2::ItemDefinition{
id = 'BooleanItemDefinition'
},
extensionValues = extension : esteco::DocumentRoot{
default = default : esteco::TDefault {
simpleValue = simple_value : esteco::TSimpleValue {
value = 'false'
}
}
}
}
};
}
relation propertyVerbose {
checkonly domain source g : esteco_m::TGeometry{};
enforce domain target t :bpmn2::Task {
properties = verbose : bpmn2::Property {
-- el id lo genera solo
name = 'verbose',
itemSubjectRef = item : bpmn2::ItemDefinition{
id = 'BooleanItemDefinition'
},
extensionValues = extension : esteco::DocumentRoot{
default = default : esteco::TDefault {
simpleValue = simple_value : esteco::TSimpleValue {
value = 'false'
}
}
}
}
};
}
relation propertyLabel {
136
checkonly domain source g : esteco_m::TGeometry{};
primitive domain name_task:String;
enforce domain target t :bpmn2::Task {
properties = label : bpmn2::Property {
-- el id lo genera solo
name = 'label',
itemSubjectRef = item : bpmn2::ItemDefinition{
id = 'StringItemDefinition'
},
extensionValues = extension : esteco::DocumentRoot{
default = default : esteco::TDefault {
simpleValue = simple_value : esteco::TSimpleValue {
value = name_task
}
}
}
}
};
}
relation propertyDescription {
checkonly domain source g : esteco_m::TGeometry{};
enforce domain target t :bpmn2::Task {
properties = description : bpmn2::Property {
-- el id lo genera solo
name = 'description',
itemSubjectRef = item : bpmn2::ItemDefinition{
id = 'StringItemDefinition'
},
extensionValues = extension : esteco::DocumentRoot{
default = default : esteco::TDefault {
simpleValue = simple_value : esteco::TSimpleValue {
value = ''
}
}
}
}
};
}
} --Fin de la transformacion
137
Anexo B
Código del Caso de Estudio
<?xml version="1.0" encoding="UTF-8"?>
<esteco_m:TGeometry xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:esteco_m="http://www.esteco.com" xsi:schemaLocation="http://www.esteco.com
../metamodel/Esteco_M.ecore">
<startNode id="_12" name="Start12">
<endConnector id="_12_2"/>
</startNode>
<exitNode id="_14" name="Exit14">
<startConnector id="_14_0"/>
</exitNode>
<taskNode id="17" name="GTSuite17" charset="US-ASCII" relative="false" termination="DOS" timeout="0"
type="it.esteco.integration.gtsuite.workflow.GTSuiteNode"
model="D:\users\Alberto\GT_POWER_CLUSTERING\cyloptBV70.gtm">
<startConnector id="_17_0"/>
<endConnector id="_17_2"/>
<bufferInputDataConnector id="_17_1"/>
<bufferOutputDataConnector id="_17_3"/>
<inputFileConnector id="_17_1F"/>
<outputFileConnector id="_17_3F"/>
</taskNode>
<inputDataNode id="_1" name="INTCAM" type="it.esteco.procint.workflow.InputNode" expression=""
kind="VARIABLE" value="0.0">
<outputDataConnector id="_1_2"/>
</inputDataNode>
<inputDataNode id="_2" name="EXHCAM" type="it.esteco.procint.workflow.InputNode" expression=""
kind="VARIABLE" value="0.0">
<outputDataConnector id="_2_2"/>
</inputDataNode>
<inputDataNode id="_3" name="INTRUNLENGTH" type="it.esteco.procint.workflow.InputNode"
expression="" kind="VARIABLE" value="0.0">
<outputDataConnector id="_3_2"/>
</inputDataNode>
<inputDataNode id="_4" name="TH50" type="it.esteco.procint.workflow.InputNode" expression=""
kind="VARIABLE" value="0.0">
<outputDataConnector id="_4_2"/>
</inputDataNode>
<outputDataNode id="_8" name="BSFC" type="it.esteco.procint.workflow.OutputNode">
<inputDataConnector id="_8_0"/>
<outputDataConnector id="_8_2"/>
</outputDataNode>
<outputDataNode id="_9" name="NOX" type="it.esteco.procint.workflow.OutputNode">
<inputDataConnector id="_9_0"/>
<outputDataConnector id="_9_2"/>
</outputDataNode>
<dataEdge from="_17_3" to="_8_0"/>
138
<dataEdge from="_4_2" to="_17_1"/>
<dataEdge from="_1_2" to="_17_1"/>
<dataEdge from="_3_2" to="_17_1"/>
<dataEdge from="_17_3" to="_9_0"/>
<dataEdge from="_2_2" to="_17_1"/>
<processEdge from="_12_2" to="_17_0"/>
<processEdge from="_17_2" to="_14_0"/>
</esteco_m:TGeometry>
139
Anexo C
Código generado por la transformación del Caso
de Estudio <?xml version="1.0" encoding="UTF-8"?>
<bpmn2:Definitions xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:bpmn2="http://www.omg.org/spec/BPMN/20100524/MODEL-XMI"
xmlns:esteco="http://www.esteco.com"
xsi:schemaLocation="http://www.omg.org/spec/BPMN/20100524/MODEL-XMI ../metamodel/BPMN20.ecore
http://www.esteco.com ../metamodel/esteco.ecore" id="_u45j4SthEeOotIiqjt66Mg">
<imports importType="http://www.w3.org/2001/XMLSchema" location="calculatorParameterModel.xsd"
namespace="http://www.esteco.com"/>
<imports importType="http://www.w3.org/2001/XMLSchema" location="esteco.xsd"
namespace="http://www.esteco.com"/>
<rootElements xsi:type="bpmn2:ItemDefinition" id="DoubleItemDefinition" structureRef="xsd:double"/>
<rootElements xsi:type="bpmn2:ItemDefinition" id="StringItemDefinition" structureRef="xsd:string"/>
<rootElements xsi:type="bpmn2:ItemDefinition" id="AnyTypeItemDefinition" structureRef="xsd:any"/>
<rootElements xsi:type="bpmn2:ItemDefinition" id="tCalculatorParameterModel"
structureRef="esteco:tCalculatorParameterModel"/>
<rootElements xsi:type="bpmn2:ItemDefinition" id="tGTSuiteParameterModel"
structureRef="esteco:tTGSuiteParameterModel"/>
<rootElements xsi:type="bpmn2:ItemDefinition" id="FloatItemDefinition" structureRef="xsd:float"/>
<rootElements xsi:type="bpmn2:ItemDefinition" id="DoubleArrayItemDefinition"
structureRef="esteco:array"/>
<rootElements xsi:type="bpmn2:ItemDefinition" id="DoubleMatrixItemDefinition"
structureRef="esteco:matrix"/>
<rootElements xsi:type="bpmn2:ItemDefinition" id="IntItemDefinition" structureRef="xsd:int"/>
<rootElements xsi:type="bpmn2:ItemDefinition" id="BooleanItemDefinition" structureRef="xsd:boolean"/>
<rootElements xsi:type="bpmn2:ItemDefinition" id="AnyURIItemDefinition" structureRef="xsd:anyURI"/>
<rootElements xsi:type="bpmn2:Process" id="EstecoMainProcess" name="EstecoMainProcess"
isExecutable="true" processType="Private">
<ioSpecification id="_u5YFACthEeOotIiqjt66Mg">
<dataInputs id="_1" itemSubjectRef="DoubleItemDefinition" name="INTCAM"/>
<dataInputs id="_2" itemSubjectRef="DoubleItemDefinition" name="EXHCAM"/>
<dataInputs id="_3" itemSubjectRef="DoubleItemDefinition" name="INTRUNLENGTH"/>
<dataInputs id="_4" itemSubjectRef="DoubleItemDefinition" name="TH50"/>
<dataOutputs id="_8" itemSubjectRef="DoubleItemDefinition" name="BSFC"/>
<dataOutputs id="_9" itemSubjectRef="DoubleItemDefinition" name="NOX"/>
<inputSets id="_u5eLoythEeOotIiqjt66Mg" dataInputRefs="_1 _2 _3 _4"/>
<outputSets id="_u5kSQithEeOotIiqjt66Mg" dataOutputRefs="_8 _9"/>
</ioSpecification>
<flowElements xsi:type="bpmn2:StartEvent" id="_12" name="Start12"
outgoing="_u5L3withEeOotIiqjt66Mg"/>
<flowElements xsi:type="bpmn2:SequenceFlow" id="_u5L3withEeOotIiqjt66Mg" sourceRef="_12"
targetRef="17"/>
140
<flowElements xsi:type="bpmn2:EndEvent" id="_14" name="Exit14" incoming="_u5R-
YithEeOotIiqjt66Mg"/>
<flowElements xsi:type="bpmn2:SequenceFlow" id="_u5R-YithEeOotIiqjt66Mg" sourceRef="17"
targetRef="_14"/>
<flowElements xsi:type="bpmn2:Task" id="17" name="GTSuite17" incoming="_u5L3withEeOotIiqjt66Mg"
outgoing="_u5R-YithEeOotIiqjt66Mg">
<extensionValues xsi:type="esteco:DocumentRoot">
<providerKey value="GTSuiteNode"/>
</extensionValues>
<ioSpecification id="_u5kSQythEeOotIiqjt66Mg">
<dataInputs id="_1_T17" itemSubjectRef="DoubleItemDefinition" name="INTCAM">
<extensionValues xsi:type="esteco:DocumentRoot">
<default>
<simpleValue value="0"/>
</default>
</extensionValues>
</dataInputs>
<dataInputs id="_2_T17" itemSubjectRef="DoubleItemDefinition" name="EXHCAM">
<extensionValues xsi:type="esteco:DocumentRoot">
<default>
<simpleValue value="0"/>
</default>
</extensionValues>
</dataInputs>
<dataInputs id="_3_T17" itemSubjectRef="DoubleItemDefinition" name="INTRUNLENGTH">
<extensionValues xsi:type="esteco:DocumentRoot">
<default>
<simpleValue value="0"/>
</default>
</extensionValues>
</dataInputs>
<dataInputs id="_4_T17" itemSubjectRef="DoubleItemDefinition" name="TH50">
<extensionValues xsi:type="esteco:DocumentRoot">
<default>
<simpleValue value="0"/>
</default>
</extensionValues>
</dataInputs>
<dataOutputs id="_8_T17" itemSubjectRef="DoubleItemDefinition" name="BSFC"/>
<dataOutputs id="_9_T17" itemSubjectRef="DoubleItemDefinition" name="NOX"/>
<inputSets id="_u59T0CthEeOotIiqjt66Mg" dataInputRefs="_1_T17 _2_T17 _3_T17 _4_T17"/>
<outputSets id="_u59T0ythEeOotIiqjt66Mg" dataOutputRefs="_8_T17 _9_T17"/>
</ioSpecification>
<properties id="_u6PnsSthEeOotIiqjt66Mg" itemSubjectRef="StringItemDefinition" name="charset">
<extensionValues xsi:type="esteco:DocumentRoot">
<default>
<simpleValue value="calculator.charset.US-ASCII"/>
</default>
</extensionValues>
</properties>
<properties id="_u6PntSthEeOotIiqjt66Mg" itemSubjectRef="IntItemDefinition" name="timeout">
<extensionValues xsi:type="esteco:DocumentRoot">
141
<default>
<simpleValue value="0"/>
</default>
</extensionValues>
</properties>
<properties id="_u6PnuSthEeOotIiqjt66Mg" itemSubjectRef="StringItemDefinition" name="model">
<extensionValues xsi:type="esteco:DocumentRoot">
<default>
<simpleValue value="D:\users\Alberto\GT_POWER_CLUSTERING\cyloptBV70.gtm"/>
</default>
</extensionValues>
</properties>
<properties id="_u6h7kCthEeOotIiqjt66Mg" itemSubjectRef="tGTSuiteParameterModel"
name="INTCAM">
<extensionValues xsi:type="esteco:DocumentRoot">
<default>
<complexValue>
<tgSuiteParameterModel datatype="xsd.double" name="INTCAM"/>
</complexValue>
</default>
<dataInterfaceRef value="_1_T17"/>
</extensionValues>
</properties>
<properties id="_u6oCMCthEeOotIiqjt66Mg" itemSubjectRef="tGTSuiteParameterModel"
name="EXHCAM">
<extensionValues xsi:type="esteco:DocumentRoot">
<default>
<complexValue>
<tgSuiteParameterModel datatype="xsd.double" name="EXHCAM"/>
</complexValue>
</default>
<dataInterfaceRef value="_2_T17"/>
</extensionValues>
</properties>
<properties id="_u6oCNithEeOotIiqjt66Mg" itemSubjectRef="tGTSuiteParameterModel"
name="INTRUNLENGTH">
<extensionValues xsi:type="esteco:DocumentRoot">
<default>
<complexValue>
<tgSuiteParameterModel datatype="xsd.double" name="INTRUNLENGTH"/>
</complexValue>
</default>
<dataInterfaceRef value="_3_T17"/>
</extensionValues>
</properties>
<properties id="_u6uI0CthEeOotIiqjt66Mg" itemSubjectRef="tGTSuiteParameterModel" name="TH50">
<extensionValues xsi:type="esteco:DocumentRoot">
<default>
<complexValue>
<tgSuiteParameterModel datatype="xsd.double" name="TH50"/>
</complexValue>
</default>
142
<dataInterfaceRef value="_4_T17"/>
</extensionValues>
</properties>
<properties id="_u6uI1ithEeOotIiqjt66Mg" itemSubjectRef="tGTSuiteParameterModel" name="BSFC">
<extensionValues xsi:type="esteco:DocumentRoot">
<default>
<complexValue>
<tgSuiteParameterModel datatype="xsd.double" name="BSFC"/>
</complexValue>
</default>
<dataInterfaceRef value="_8_T17"/>
</extensionValues>
</properties>
<properties id="_u6uI3CthEeOotIiqjt66Mg" itemSubjectRef="tGTSuiteParameterModel" name="NOX">
<extensionValues xsi:type="esteco:DocumentRoot">
<default>
<complexValue>
<tgSuiteParameterModel datatype="xsd.double" name="NOX"/>
</complexValue>
</default>
<dataInterfaceRef value="_9_T17"/>
</extensionValues>
</properties>
<dataInputAssociations id="_u6DacCthEeOotIiqjt66Mg" sourceRef="_1" targetRef="_1_T17"/>
<dataInputAssociations id="_u6DacSthEeOotIiqjt66Mg" sourceRef="_2" targetRef="_2_T17"/>
<dataInputAssociations id="_u6DacithEeOotIiqjt66Mg" sourceRef="_3" targetRef="_3_T17"/>
<dataInputAssociations id="_u6JhECthEeOotIiqjt66Mg" sourceRef="_4" targetRef="_4_T17"/>
<dataOutputAssociations id="_u6JhESthEeOotIiqjt66Mg" sourceRef="_8_T17" targetRef="_8"/>
<dataOutputAssociations id="_u6PnsCthEeOotIiqjt66Mg" sourceRef="_9_T17" targetRef="_9"/>
</flowElements>
</rootElements>
</bpmn2:Definitions>
143
Referencias
[1] Cui Lin, Shiyong Lu, Xubo Fei, Artem Chebotko, Darshan Pai et al. “A reference
architecture for scientific workflow management systems and the VIEW SOA solution”.
IEEE Transactions on Service Computing, vol. 2, no. 1, pp. 79-92. 2009.
[2] ESTECO SpA. “modeFRONTIER applications across industrial sectors involving
advanced CAD/CAE packages”. www.esteco.com último acceso 25/10/2013.
[3] Carlo Comin, Luka Onesti, and Carlos Kavka. “Towards a Standard Approach for
Optimization in Science and Engineering”. Proceedings of the 8th International
Conference on Software Engineering and Applications ICSOFT-EA, SciTePress, 2013.
[4] OMG document number: “Business process model and notation”. formal/2011-01-03
http://www.omg.org/spec/BPMN/2.0/ último acceso 26/07/2013.
[5] Business Process Modeling Initiative http://www.bpmi.org/ último acceso 26/07/2013.
[6] Object Management Group, MDA Guide, v1.0.1, http://www.omg.org/cgi-
bin/doc?omg/03-06-01 último acceso 26/07/2013.
[7] Anneke Kleppe, Jos Warmer, Wim Bast. “MDA Explained: The Model Driven
Architecture™: Practice and Promise” Addison-Wesley Longman Publishing Co., Inc.,
Boston, MA, USA, 2003.
[8] T Stahl and M. Völter. “Model-Driven Software Development”. John Wiley & Sons, Ltd.
2006.
[9] Jean-Marie Favre, Jacky Estublier, Mireille Blay. “Beyond MDA : Model Driven
Engineering” (L'Ingénierie Dirigée par les Modèles : au-délà du MDA) Edition Hezmes-
Lavoisier, ISBN 2-7462-1213-7. 2006.
[10] Object Management Group (OMG). “Modeling and metadata specifications”.
http://www.omg.org/spec, último acceso 26/07/2013.
[11] Corina Abdelahad, Daniel Riesco, Carlo Comin, Alessandro Carrara, and Carlos Kavka
"Towards the Standardization of Industrial Scientific and Engineering Workflows with
QVT Transformations”. International Journal On Advances in Software, Soft13v6n12,
2013.
[12] Corina Abdelahad, Daniel Riesco, Carlo Comin, Alessandro Carrara, and Carlos Kavka.
“Data Transformations using QVT between Industrial Workflows and Business Models in
BPMN”. Proceedings of the Seventh International Conference on Software Engineering
Advances ICSEA, IARIA, 2012.
[13] Corina Abdelahad, Daniel Riesco, Carlo Comin, Alessandro Carrara, and Carlos Kavka.
“Hacia una estandarización de workflows científicos e industriales con BPMN2”
144
Congreso Nacional de Ingeniería Informática /Sistemas de Información CoNaIISI‟2013,
2013.
[14] UML 2.1.2“Infrastructure Specification” www.omg.org/spec/UML/2.4.1/ último acceso
28/07/2013.
[15] OMG document number: “Business process model and notation”. formal/2008-01-17
http://www.omg.org/spec/BPMN/1.1/ último acceso 9/11/2013.
[16] Bertram Ludascher, Ilkay Altintas, Shawn Bowers, Julian Cummings, Terence Critchlow
et al. “Scientific Process Automation and Workflow Management”. in “Scientific Data
Management: Challenges, Technology, and Deployment”. edited by A. Shoshan and D.
Rotem, Chapman and Hall/CDC, 2009.
[17] Ian Taylor, Matthew Shields, Ian Wang, and Andrew Harrison. “The Triana workflow
environment: architecture and applications”. in “Workflows for e-Science: Scientific
Workflows for Grids”. pp 320-339, Springer, 2007.
[18] Pablo Missier, Stian Soiland-Reyes, Stuart Owen, Wei Tan, Alexrandra Nenadic et al.
“Taverna, Reloaded”. Lecture Notes in Computer Science, vol. 6187, pp. 471-481,
Springer, 2010.
[19] Mirko Sonntag, Dimka Karastoyanova, and Ewa Deelman. “Bridging The Gap Between
Business And Scientific Workflows”. Proceedings of the ESCIENCE 2010, 6th IEEE
International Conference on e-Science, IEEE Computer Society, 2010.
[20] Michael Berthold, Nicolas Cebtron, Fabian Dill, Thomas R. Gabriel, Tobias Kotter et al.
“KNIME: The Konstanz Information Miner”. in “Data Analysis, Machine Learning and
Applications”. ed. H. Bock, W. Gaul, M. Vichi, pp. 319-326, Springer, 2008.
[21] Henning Heitkoetter. “Transforming PICTURE to BPMN 2.0 as part of the model-driven
development of electronic government systems”. 44th Hawaii International Conference
on System Sciences (HICSS), pp. 1-10, 2011.
[22] Paolo Bocciarelli and Andrea D'Ambrogio. “A BPMN extension for modeling non
functional properties of business processes”. TMS-DEVS'11 Proceedings of the 2011
Symposium on Theory of Modeling & Simulation: DEVS Integrative M&S Symposium,
Springer-Verlag, pp. 160-168, 2011.
[23] Narayan Debnath, Carlos Alejandro Martinez, Fabio Zorzan, Daniel Riesco, and German
Montejano. “Transformation of business process models BPMN 2.0 into components of
the Java business platform". Industrial Informatics (INDIN), 10th IEEE International
Conference on Digital Objects, pp. 1035-1040, IEEE, 2012.
[24] Nima Hashemian and Samina Sibte Raza Abidi. “Modeling clinical workflows using
business process modeling notation”. Computer-Based Medical Systems (CBMS), 25th
International Symposium on Digital Object, pp. 1-4, IEEE, 2012.
145
[25] Guillaume Doux, Frédéric Jouault, and Jean Bézivin. “Transforming BPMN process
models to BPEL process definitions with ATL” Fifth International Workshop on Graph-
Based Tools - Grabats 2009 (co-located with TOOLS 2009) Zurich, Switzerland, 2009.
[26] Mauro Argañaraz, Ana Funes, Aristides Dasso. “An MDA Approach to Business Process
Model Transformations” Electronical Journal of Sadio (EJS), 2010.
[27] Behzad Bordbar, Athanasios Staikopoulos. “On behavioural model transformation in Web
services”. 5th International Workshop on Conceptual Modeling Approaches for e-
Business eCOMO'2004, 2004.
[28] Jean Bézivin, Slimane Hammoudi, Denivaldo Lopes, Frédéric Jouault. “Applying MDA
Approach to B2B Applications: A Road Map” Workshop on Model Driven Development
(WMDD 2004) at ECOOP 2004, LNCS, vol. 3344, Springer-Verlag, 2004.
[29] Marcel van Amstel, Steven Bosems, Ivan Kurtev, and Luís Ferreira Pires. “Performance
in model transformations: experiments with ATL and QVT”. Lecture Notes in Computer
Science, Vol. 6707, Theory and Practice of Model Transformations, pp. 198-212,
Springer, 2011.
[30] Ali Fatolahi, Stéphane Somé, and TimothyLethbridge. “Automated generation of abstract
web models using QVT relations”. Technical Report TR-2010-06, School of Information
Technology and Engineering, University of Ottawa, 2010.
[31] Matjaž B. Jurič and Kapil Pant. “Business Process Driven SOA using BPMN and BPEL”.
Editor Packt Publishing Ltd, 2008.
[32] Yolanda Gil, Ewa Deelman, Mark Ellisman, Thomas Fahringer, Geoffrey Fox, Dennis
Gannon, Carole Goble, Miron Livny, Luc Moreau and Jim Myers. “Examining the
challenges of scientific workflows”. vol. 40, no. 12, pp. 24-32, IEEE Computer, 2007.
[33] Rob Allen. “The Workflow Handbook 2001”. Open Image Systems Inc., United Kingdom
Chair, WfMC External Relations Committee; Workflow Management Coalition; 2001.
[34] Li Hongbiao, Li Feng and Yu Wanjun. “The research of scientific workflow engine”.
IEEE International Conference on Software Engineering and Service Sciences (ICSESS),
pp. 412-414, 2010.
[35] Gideon Juve and Ewa Deelman. “Scientific workflows and clouds”. ACM Crossroads
vol. 16,no. 3, pp. 14-18, 2010.
[36] Stephen A. White. “Introduction to BPMN”. Technical Report, IBM Corporation,
www.omg.org/bpmn/Documents/Introduction_to_BPMN.pdf, último acceso 11/10/2013.
[37] Stephen A. White and Derek Miers. “BPMN Modeling and Reference Guide:
Understanding and Using BPMN”. ISBN: 9780977752720, Future Strategies Inc., 2008.
[38] Bruce Silver. “BPMN Method and Style”. 2nd Edition, with Bpmn Implementer's Guide:
146
A Structured Approach for Business Process Modeling and Implementation Using Bpmn
2.0. ISBN: 9780982368114, publisher: Cody-Cassidy Press, 2011.
[39] D. Hollingsworth. “The Workflow Reference Model”. Version 1.1. Technical Report
WFMC-TC-1003. Workflow Management Coalition, 1995.
[40] B. Kiepuszewski. “Expressiveness and Suitability of Languages for Control Flow
Modelling in Workflows”. PhD thesis. Queensland University of Technology. Australia,
2002.
[41] Bertram Ludäscher, Ilkay Altintas, Chad Berkley, Dan Higgins, Efrat Jaeger, Matthew
Jones, Edwars A. Lee, Jing Taoand and Yang Zhao. “Scientific workflow management
and the Kepler system: Research Articles”. John Wiley and Sons Ltd, Concurr. Comput. :
Pract. Exper., vol. 18, no. 10, ISSN: 1532-0626, pp: 1039-1065, url:
http://dx.doi.org/10.1002/cpe.v18:10, 2006.
[42] Jia Yu and Rajkumar Buyya. “A Taxonomy of Scientific Workflow Systems for Grid
Computing” ACM, SIGMOD Rec., vol. 34, no. 3, ISSN: 0163-5808, url:
http://doi.acm.org/10.1145/1084805.1084814, 2005.
[43] Kheiredine Derouiche and Denis A. Nicole. “Semantically Resolving Type Mismatches in
Scientific Workflows”. ISSNs: 0302-9743, Springer Berlin / Heidelberg, 2007.
[44] E.F. Moore. “Gedanken experiments on sequential machines”. In Automata Studies, pp.
129–153. Princeton University., 1956.
[45] J. Gutierrez, M. Escalona, A. Torres, M. Mejías, J.Torres. “Hacia una propuesta de
Pruebas Tempranas del Sistema” Jornadas de Ingeniería del Software y Bases de Datos
(JISBD), Workshop PRIS 2006.
[46] Roxana Giandini, Claudia Pons, Gabriela Pérez . “A two-level formal semantics for the
QVT language” Memorias de la XII Conferencia Iberoamericana en Software
Engineering (CIbSE). Medellín, Colombia, ISBN: 978-958-44-5028-9, Pag: 73-86, 2009.
[47] UML 2.1.2“Infrastructure Specification” http://www.omg.org/spec/UML/2.2/ 2009
último acceso 15/11/2012.
[48] OMG document number: Formal/2011-01-01 http://www.omg.org/spec/QVT/1.1/ último
acceso 15/10/2013.
[49] MDA http://www.omg.org/mda/ último acceso 15/10/2013.
[50] David S. Frankel. “Model Driven ArchitectureTM
– Applying MDATM
to Esterprise
computing”. ISBN 978-0-471-31920-7. Ed: Wiley Publishing, Inc, 2003.
[51] Jesús Rodríguez Vicente. “Ingeniería de Modelos con MDA: Estudio comparativo de
OptimalJ y ArcStyler”. Departamento de Informática y Sistemas, Universidad de Murcia.
2004.
147
[52] An introduction to Model Driven Architecture
http://www.ibm.com/developerworks/rational/library/3100.html último acceso
11/10/2013.
[53] Miller & Mukerji. “Model Driven Architecture (MDA)”. Document number ormsc/2001-
07-01. Architecture Borrad ORMSC, 2001.
[54] MOF: http://www.omg.org/mof/ último acceso 15/10/2013.
[55] J. Bézivin. “MDA: From Hype to Hope, and Reality”. Conferenciante invitado en
UML‟03, 2003.
[56] Stuart Kent. “Model driven engineering. In Integrated Formal Methods”. Third
International Conference, IFM 2002, Turku, Finland, May 15-18, 2002, Proceedings, vol.
2335, Lecture Notes in Computer Science, pp. 286–298. Springer-Verlag, 2002.
[57] MDA Specifications http://www.omg.org/mda/specs.htm último acceso 15/10/2013.
[58] Mens, Tom and Van Gorp, Pieter. “A Taxonomy of Model Transformation”. Electronic
Notes in Theoretical Computer Science (ENTCS) vol. 152, pp. 125-142, 2006.
[59] IKV. The Medini QVT project. http://projects.ikv.de/qvt, último acceso 15/10/2013.
[60] ESTECO SpA, Multiobjective Optimization in Engine Design using Genetic Algorithms
to Improve Engine Performance, ESTECO resource center, http://www.esteco.com.