Universidad Nacional de San Luis
Facultad de Ciencias Físico Matemáticas y Naturales Departamento de Informática
Tesis de Maestría en Ingeniería de Software
Transformación de Modelos de Procesos del Negocio BPMN 2.0 a
Componentes de la Capa del Negocio Java
Autor: Ing. Carlos Alejandro Martinez
Director: Dr. Daniel Riesco Codirector: Mg. Fabio Zorzan
I
Agradecimientos
En primer lugar quiero agradecer a mi familia, por toda la ayuda, motivación y preocupación que han mostrado por mí. Mi esposa, Roxana y mis hijos Agustina, Lautaro y Santino.
Al Dr. Daniel Riesco con quien he crecido académica y profesionalmente. Agradezco en especial sus enseñanzas, su apoyo y constante motivación.
Al Mg. Fabio Zorzan, quien aportó toda su experiencia como postgraduado; sin su ayuda hubiera sido mucho más difícil el desarrollo de la tesis. Sus valiosos consejos han contribuido a lograr los objetivos propuestos.
A todas las personas que con sus aportes han contribuido a la mejora de esta Tesis de Maestría. En especial a Sandy Soler Martínez de la Universidad de Olguín en Cuba. A mis compañeros de trabajo, amigos y colegas que han colaborado y han influido de alguna forma para que elabore y termine la tesis.
II
Resumen
La mejora continua en las organizaciones implica rediseñar, mejorar o introducir nuevos procesos de negocio de forma eficaz y eficiente manteniendo su integración con los sistemas informáticos de la organización. Este trabajo contribuye con transformaciones que permiten generar componentes del negocio Java EE vinculados a procesos del negocio permitiendo mejorar la productividad en el desarrollo y aumentar la calidad del software al disminuir errores de diseño.
Las organizaciones de la actualidad están en permanente cambio siendo una necesidad tener automatizados total o parcialmente sus procesos de negocio. Por esta razón, es imprescindible mantener la articulación entre los procesos del negocio y los sistemas informáticos. Las transformaciones en el contexto de MDA es una alternativa válida para cumplir con este objetivo.
En esta Tesis de Maestría, se presenta una propuesta para que mediante transformaciones de un modelo BPMN 2.0 ejecutable se obtenga código desplegable en un servidor Java EE. La propuesta demuestra que a partir de la información contenida en un diagrama BPMN 2.0 ejecutable se puede obtener un prototipo de una aplicación Enterprise Java EE . Se parte de un diagrama BPMN 2.0 ejecutable y a través de transformaciones se obtienen componentes Java Enterprise.
El modelo BPMN 2.0 ejecutable se transforma a un modelo UML 2 con anotaciones de un perfil independiente de la tecnología. En base al modelo UML 2 con la aplicación de estereotipos independientes de la tecnología se genera un modelo UML 2 específico de la plataforma Java EE. Al basarse en UML2 estándar el desarrollador puede tomar los modelos UML de las transformaciones y agregar los detalles necesarios que permitan cumplir con los requerimiento del usuario.
Se define un método trabajo diseñado para lograr el desarrollo de las transformaciones siguiendo un proceso continuo, iterativo e incremental. Como resultado de aplicar este proceso se obtienen las transformaciones QVT validadas para ser utilizadas en producción. Las versiones de las transformaciones evolucionan utilizando casos de estudios reales y de laboratorio.
Las transformaciones desarrolladas cumplen con los objetivos de: alinear procesos del negocio con los sistemas informáticos y mejorar la productividad en el desarrollo de software vinculado a procesos del negocio. Las transformaciones permiten aumentar la productividad en el desarrollo ya que generan rápidamente un prototipo que puede ser modificado por el desarrollador.
III
Índice
1. INTRODUCCIÓN ... 1 1.1 MOTIVACIÓN ... 1 1.2 OBJETIVOS DE LA TESIS ... 2 1.3 METODOLOGÍA DE TRABAJO ... 3 1.4 ESTRUCTURA DE LA TESIS ... 6 2. CONCEPTOS BÁSICOS ... 72.1 ARQUITECTURA DIRIGIDA POR MODELOS ... 7
2.2 METAMODELOS Y ARQUITECTURA MOF ... 8
2.2.1 Nivel M3 (Meta-metamodelo) ... 8
2.2.2 Nivel M2 (Metamodelo)... 8
2.2.3 Nivel M1 (Modelo) ... 8
2.2.4 Nivel M0 (Instancias)... 8
2.3 TRANSFORMACIONES CON QUERY VIEW TRANSFORMATION (QVT) ... 9
2.3.1 Transformaciones ... 9 2.3.2 QVT-QVT/Relations... 10 2.3.3 QVT Relations ... 11 2.3.4 Herramienta Medini-QVT ... 17 2.3.5 Herramienta Acceleo ... 18 2.3.6 Perfiles UML ... 21
2.4 BPMN 2 (BUSINESS PROCESS MODELING NOTATION 2) ... 23
2.4.1 Gestión de Procesos del Negocio (Business Process Management-BPM) ... 23
2.4.2 BPMS ... 26
2.4.3 BPMN Framework ... 27
2.4.4 Notación de BPMN 2.0 ... 28
2.4.5 Diagrama de Colaboración ... 36
2.4.6 Modelado de Diagramas BPMN 2.0 Ejecutables ... 37
2.4.7 Intercambio de Modelos ... 39
2.5 COMPONENTES DEL NEGOCIO JAVA EE ... 40
2.5.1 Introducción ... 40
2.5.2 Enterprise Java Beans ... 41
2.5.3 Web Services ... 48
2.5.4 Java Persistent API (JPA)... 50
3. ESTADO DEL ARTE ... 58
3.1 MDA Y PROCESOS DEL NEGOCIO ... 59
3.1.1 Arquitectura Dirigida por Modelos ... 59
3.1.2 Modelado de Procesos del Negocio y BPMN... 59
3.1.3 BPM y BPMS ... 60
3.2 TRABAJOS RELACIONADOS ... 61
3.2.1 Criterios de Análisis de las propuestas ... 61
3.2.2 Transformaciones de Procesos del Negocio a UML y SoaML ... 62
3.2.3 Análisis de Transformaciones de Procesos del Negocio a UML y SoaML ... 65
3.2.4 Transformaciones de PIM a PSM y de PSM a código ... 66
3.2.5 Análisis de Transformaciones de PIM a PSM y de PSM a código ... 67
3.3 CONCLUSIONES ... 68
4. TRANSFORMACIÓN DE MODELOS DE PROCESOS DEL NEGOCIO BPMN 2.0 A COMPONENTES DE LA CAPA DEL NEGOCIO JAVA EE ... 70
IV
4.1.1 Relación de la Propuesta con Otros Componentes Vinculados a la Arquitectura de una
Aplicación SOA ... 72
4.1.2 Definición de las Transformaciones con QVT ... 74
4.2 TRANSFORMACIÓN DE BPMN 2 A UML 2 ... 74
4.2.1 Ejemplo Genérico de Transformación de BPMN 2 a UML 2... 75
4.2.2 Perfil Independiente de la Tecnología ... 78
4.2.3 Generación de modelo UML 2 con paquetes: entities y business ... 79
4.2.4 Transformación de un elemento Process de BPMN 2.0 a un elemento Class UML 2.0 ... 81
4.2.5 Transformación de un elemento Lane de BPMN 2.0 a un elemento Class UML 2.0 ... 82
4.2.6 Transformación de un elemento ServiceTask de BPMN 2.0 a un elemento Operation de una Clase UML 2.0 ... 84
4.2.7 Transformación de un elemento DataStore de BPMN 2.0 a elementos Operation de una Clase UML 2.0 ... 86
4.2.8 Transformación de un modelo BPMN 2.0 a Elementos Generales UML2 ... 87
4.2.9 Transformación de un elemento DataStore a elementos UML 2 ... 88
4.2.10 Transformación de un elemento Lane de BPMN 2.0 a un elemento Class UML 2.0 ... 90
4.2.11 Transformación de un elemento Participant de BPMN 2.0 a un elemento Class UML 2.0 ... 92
4.3 TRANSFORMACIÓN DE UN MODELO UML2 CON PERFIL INDEPENDIENTE DE LA TECNOLOGÍA A UN MODELO UML2 CON PERFIL EJB3.1-JPA2 ... 94
4.3.1 Ejemplo de Transformación de UML2 con perfil independiente de la tecnología a UML2 con perfil Ejb3.1-JPA2 ... 95
4.3.2 Perfil Java EE ... 98
4.3.3 Perfil JPA2 ... 99
4.3.4 Transformaciones del paquete Business ... 100
4.3.5 Transformaciones del paquete Entities ... 104
4.4 TRANSFORMACIÓN DE MODELO UML2 CON PERFIL EJB3.1-JPA2 A CÓDIGO FUENTE JAVAEE... 107
4.4.1 Ejemplo de UML2 con perfil Ejb3.1-JPA2 a Código Fuente JavaEE ... 108
4.4.2 Estructura del Proyecto Acceleo ... 111
4.4.3 Transformaciones del Paquete Business ... 113
4.4.4 Transformación del Paquete Entities... 116
4.5 CONCLUSIONES ... 119
5. APLICACIÓN DEL MÉTODO DE TRABAJO Y CASOS DE ESTUDIO ... 121
5.1 APLICACIÓN DEL MÉTODO DE TRABAJO ... 121
5.1.1 Método de Trabajo Aplicado a la Transformación de BPMN 2 a UML 2 con perfil independiente de la plataforma ... 122
5.1.2 Método de Trabajo Aplicado a la transformación de un modelo UML2 con perfil independiente de la plataforma a un modelo UML2 con perfil Ejb3.1-JPA2 ... 123
5.1.3 Método de Trabajo Aplicado a la transformación de un modelo UML2 con perfil Ejb3.1-JPA2 a Código Fuente JavaEE... 124
5.2 VERSIONES DESARROLLADAS DE LAS TRANSFORMACIONES... 125
5.3 CASOS DE ESTUDIO DE LABORATORIO Y REALES ... 125
5.4 CASO DE ESTUDIO DEL SISTEMA DE MANTENIMIENTO ... 126
5.4.1 Planteo del Problema ... 126
5.4.2 Modelo del Proceso Técnico BPMN 2 ... 128
5.4.3 Transformación de BPMN 2 a UML 2... 129
5.4.4 Transformación de UML2 a UML2 con perfil Ejb3.1-JPA2 ... 131
5.4.5 Transformacion con Acceleo ... 134
5.5 CONCLUSIONES ... 136
6. CONCLUSIONES ... 138
6.1 RESULTADOS OBTENIDOS ... 138
6.2 PRINCIPALES APORTES Y PUBLICACIONES ... 144
6.3 LÍNEAS DE TRABAJO FUTURAS ... 145
V
7. ANEXOS ... 148
7.1 ANEXO1. METAMODELO BPMN 2.0 ... 148
7.1.1 BPMN Core Structure ... 148
7.1.2 Colaboración (Collaboration) ... 153
Flujo de Mensaje (Message Flow)... 154
7.1.3 Proceso (Process) ... 155
7.1.4 Actividades (Activities) ... 157
7.1.5 Modelado de Datos ... 160
7.1.6 Carril (Lane) ... 161
7.2 ANEXO 2. METAMODELO UML 2 ... 164
7.2.1 Especificación UML 2 ... 164
7.2.2 Infraestructura (Infrastructure) ... 164
7.2.3 Superstructure ... 174
7.2.4 Perfiles (Profiles) ... 176
7.3 ANEXO 3. CASO DE ESTUDIO DE LA RAC ... 178
7.3.1 Planteo del Problema ... 178
7.3.2 Modelo del Proceso Técnico BPMN 2 ... 180
7.3.3 Transformación de BPMN 2 a UML 2 ... 181
7.3.4 Transformación de UML2 a UML2 con perfil Ejb3.1-JPA2 ... 184
7.3.5 Transformación con Acceleo ... 187
7.3.6 Conclusiones ... 190
7.4 ANEXO 4. CÓDIGO FUENTE QVT RELATIONS: TRANSFORMACIÓN DE MODELO BPMN 2.0 A MODELO UML2 CON PERFIL INDEPENDIENTE DE LA TECNOLOGÍA ... 191
7.5 ANEXO 5. CÓDIGO FUENTE QVT RELATIONS: TRANSFORMACIÓN DE UML2 CON PERFIL INDEPENDIENTE DE LA TECNOLOGÍA A UML2 CON PERFIL EJB3.1-JPA2 ... 202
7.6 ANEXO 6. CÓDIGO FUENTE DE ACCELEO: TRANSFORMACIÓN DE UML2 CON PERFIL EJB3.1-JPA2 A CÓDIGO FUENTE JAVAEE ... 212
8. REFERENCIAS ... 233
VI
Índice de Figuras
Figura 1.1 Pasos de una Iteración para obtener una Transformación ...4
Figura 1.2 Elementos Involucrados en la verificación de las transformaciones ...5
Figura 2.1 Ejemplo de arquitectura de 4 capas de modelado ...9
Figura 2.2 Relación entre PIM, PSM y los niveles MOF ... 10
Figura 2.3 Ejemplo de consulta OCL ... 11
Figura 2.4 Relación entre los metamodelos QVT ... 12
Figura 2.5 Declaración de una transformación en QVT ... 13
Figura 2.6 Ejemplo de dominios ... 14
Figura 2.7 Ejemplo de clausulas checkonly y enforce... 15
Figura 2.8 Ejemplo de relación con las claúsulas when y where ... 16
Figura 2.9 Ejemplo de coincidencia de patrones (pattern matching) ... 17
Figura 2.10 Ejemplo de Clave ... 17
Figura 2.11 Declaración de módulo ... 20
Figura 2.12 Ejemplo de módulo ... 20
Figura 2.13 Declaración de import ... 20
Figura 2.14 Ejemplo de import ... 20
Figura 2.15 Declaración de plantilla ... 20
Figura 2.16 Ejemplo de plantilla ... 20
Figura 2.17 Declaración de consulta ... 21
Figura 2.18 Ejemplo de consulta... 21
Figura 2.19 Ejemplo de Perfil ... 22
Figura 2.20 El ciclo de BPM ... 24
Figura 2.21 El ciclo de BPM ... 25
Figura 2.22 Niveles de Abstracción del BPMN Framework... 27
Figura 2.23 Tipos básicos de eventos ... 29
Figura 2.24 Algunos tipos de eventos de inicio ... 29
Figura 2.25 Algunos tipos de eventos Intermedios ... 30
Figura 2.26 Algunos tipos de eventos de Fin ... 31
Figura 2.27 Algunos tipos de Actividades ... 31
Figura 2.28 Algunos tipos demarcadores de tareas ... 31
Figura 2.29 Tareas ... 33
Figura 2.30 Compuertas ... 33
Figura 2.31 Depósito de datos ... 34
Figura 2.32 Conectores de objetos ... 35
Figura 2.33 Canales... 36
Figura 2.34 Artefactos ... 36
Figura 2.35 Ejemplo de Diagrama Ejecutable BPMN 2 ... 37
Figura 2.36 Ejemplo de Diagrama Ejecutable BPMN 2 ... 39
Figura 2.37 Ejemplo de contenedor Ejb3 ... 42
Figura 2.38 Ciclo de vida de un stateless sesión beans ... 43
Figura 2.39 Stateless Session Beans con Interface Remote ... 43
Figura 2.40 Interface Remote del Stateless Session Beans ... 44
Figura 2.41 Ciclo de vida de un stateful sesión beans ... 44
Figura 2.42 Anotación de un stateful sesión beans ... 45
Figura 2.43 Ciclo de vida de un singleton sesión beans ... 46
Figura 2.44 Anotación que identifica a un singleton sesión beans ... 46
Figura 2.45 Ciclo de vida de un message-driven bean ... 47
Figura 2.46 Ejemplo de clase MDB ... 48
Figura 2.47 Ejemplo de clase stateless session bean anotada con @WebService ... 50
Figura 2.48 Ejemplo de clase Entity ... 52
VII
Figura 2.50 Ejemplo de relación uno a muchos ... 53
Figura 2.51 Ejemplo de relación muchos a uno ... 54
Figura 2.52 Ejemplo de relación muchos a muchos ... 54
Figura 2.53 Ejemplo de inyección de dependencia del EntityManager ... 55
Figura 2.54 Ejemplo de método find sobre una entidad ... 55
Figura 2.55 Ejemplo de persistencia de una entidad ... 56
Figura 2.56 Ejemplo de eliminación de una entidad ... 56
Figura 2.57 Ejemplo de archivo persistence.xml ... 57
Figura 4.1 Resumen de la transformación propuesta... 70
Figura 4.2 Modelos MDA y el lenguaje utilizado para las transformaciones ... 71
Figura 4.3 Transformación propuesta en el marco de la arquitectura de la OMG que sustenta MOF ... 72
Figura 4.4 Componentes de la Propuesta ... 74
Figura 4.5 Ejemplo genérico de diagrama BPMN 2 ... 75
Figura 4.6 Ejemplo genérico de diagrama BPMN 2 con visualizador de formato xmi ... 75
Figura 4.7 Resultado de la Transformación BPMN 2.0 a UML 2 ... 76
Figura 4.8 Resultado de la Transformación BPMN 2.0 a UML 2. Paquete business. Vista UML 2 ... 76
Figura 4.9 Resultado de la Transformación BPMN 2.0 a UML 2. Paquete entities. Vista UML 2 ... 77
Figura 4.10 Diagrama de Clases UML 2 modificado por el desarrollador ... 77
Figura 4.11 Perfil Independiente de la Tecnología Aplicado a una operación de una clase ... 78
Figura 4.12 Perfil Independiente de la Tecnología... 78
Figura 4.13 Generación de model UML2 y Paquetes business y entities. Vista XMI. ... 79
Figura 4.14 Generación de model UML2 y Paquetes business y entities. Vista UML2. ... 80
Figura 4.15 Transformación de Definition BPMN 2.0 a Package UML2. Vista QVT Relations. ... 80
Figura 4.16 Transformación Process BPMN 2 a Class UML 2. Vista XMI. ... 81
Figura 4.17 Transformación Process BPMN 2 a Class UML 2. Vista QVT Relations. ... 82
Figura 4.18 Transformación de Lane BPMN 2 a Class UML2. Vista XMI. ... 83
Figura 4.19 Transformación de Lane BPMN 2 a Class UML2. Vista QVT Relations. ... 84
Figura 4.20 Transformación de ServiceTask BPMN 2 a Operation UML 2. Vista XMI... 85
Figura 4.21 Transformación de ServiceTask BPMN 2 a Operation UML 2. Vista UML 2. ... 85
Figura 4.22 Transformación de ServiceTask BPMN 2 a Operation UML 2. Vista QVT Relations. ... 85
Figura 4.23 Transformación de DataStore BPMN 2 a Operaciones UML 2. Vista XMI. ... 86
Figura 4.24 Transformación de DataStore BPMN 2 a Operaciones UML 2. Vista UML 2. ... 86
Figura 4.25 Transformación de DataStore BPMN 2 a Operaciones UML 2. Vista QVT Relations. ... 87
Figura 4.26 Transformación de un modelo BPMN 2.0 a Elementos Generales UML2. Vista XMI. ... 88
Figura 4.27 Diagrama UML2 destino. Elementos Generales UML2. ... 88
Figura 4.28 Transformación de un elemento DataStore BPMN 2 a elementos UML2. Vista XMI. ... 89
Figura 4.29 Transformación de un elemento DataStore BPMN 2 a elementos UML2. Vista UML 2. ... 89
Figura 4.30 Asociación de DataStore con Entidad Lane ... 89
Figura 4.31 Parte de la transformación de un elemento DataStore BPMN 2 a elementos UML2. Vista QVT Relations. ... 90
Figura 4.32 Transformación de Lane BPMN 2.0 a un elemento Class UML 2.0.Vista XMI. ... 91
Figura 4.33 Transformación de Lane BPMN 2.0 a un elemento Class UML 2.0.Vista UML 2. ... 91
Figura 4.34 Transformación de Lane BPMN 2.0 a un elemento Class UML 2.0.Vista QVT Relations... 92
Figura 4.35 Transformación de Participant BPMN 2 a elemento Class UML 2. Vista XMI. ... 93
Figura 4.36 Transformación de Participant BPMN 2 a elemento Class UML 2. Vista UML 2. ... 93
Figura 4.37 Transformación de Participant BPMN 2 a elemento Class UML 2. Vista QVT Relations. ... 94
Figura 4.38 Diagrama de Clases UML 2 del Paquete business Modificado por el Desarrollador ... 95
Figura 4.39 Diagrama de Clases UML 2 del Paquete entities modificado por el Desarrollador ... 96
Figura 4.40 Componentes del paquete Business con Anotaciones ... 97
Figura 4.41 Componentes del paquete Entities con Anotaciones... 98
Figura 4.42 Perfil Ejb 3.1-Web Services ... 99
Figura 4.43 Perfil JPA2 ... 100
Figura 4.44 Transformación de elementos en el paquete business. Vista XMI. ... 101
Figura 4.45 Transformación de elementos en el paquete business. Vista UML 2. ... 102
VIII
Figura 4.47 Código fuente de la relación OperacionesClases. Vista QVT Relations. ... 104
Figura 4.48 Transformación de Clases del Paquete entities. Vista XMI. ... 105
Figura 4.49 Transformación de Clases del Paquete entities.. Vista QVT Relations. ... 106
Figura 4.50 Transformación de asociaciones en paquete Entity ... 107
Figura 4.51 Atributo marcado con el estereotipo <<Association>> ... 107
Figura 4.52 Diagrama de Clases UML 2 con perfil Ejb3.1-JPA2 del paquete business ... 109
Figura 4.53 Interface generada con Acceleo ... 109
Figura 4.54 Clase Stateless generada con Acceleo... 109
Figura 4.55 Clase AbstractEntityService generada con Acceleo ... 109
Figura 4.56 Diagrama de Clases UML 2 con perfil Ejb3.1-JPA2 del paquete entities ... 110
Figura 4.57 Entidad DataStore1 generada con Acceleo ... 110
Figura 4.58 Entidad DataStore1Item generada con Acceleo ... 110
Figura 4.59Entidad Lane2 generada con Acceleo ... 111
Figura 4.60 Estructura con los principales componentes del proyecto Acceleo... 111
Figura 4.61 Plantilla generarPackage ... 112
Figura 4.62 Plantilla generateWebService ... 113
Figura 4.63 Plantilla generateEntity ... 113
Figura 4.64 Diagrama XMI origen con los componentes del paquete Business ... 114
Figura 4.65 Plantilla generateCuerpoWebService del módulo cuerpoWebService ... 115
Figura 4.66 Generación de métodos de las clases del paquete Business ... 115
Figura 4.67 Método create de la Clase AbstractEntityService ... 115
Figura 4.68 Transformación de una clase a código fuente JavaEE ... 116
Figura 4.69 Diagrama XMI origen con los componentes del paquete entities ... 117
Figura 4.70 Plantilla generateCuerpoEntity del módulo cuerpoEntity ... 117
Figura 4.71 Anotación de propiedades con relaciones entre objetos ... 118
Figura 4.72 Resultado de la transformación de las clase DataStore1 ... 118
Figura 5.1 Pasos de una Iteración para obtener una Transformación ... 122
Figura 5.2 Esquema general del proceso de mantenimiento ... 127
Figura 5.3 Diagrama Técnico BPMN2 del caso de estudio Sistema de mantenimiento ... 128
Figura 5.4 Diagrama BPMN 2 con visualizador de formato xmi ... 129
Figura 5.5 Modelo resultante de la Transformación de un modelo BPMN 2.0 a un modelo UML 2 del Paquete entities ... 130
Figura 5.6 Modelo resultante de la Transformación de un modelo BPMN 2.0 a un modelo UML 2 del Paquete Business ... 131
Figura 5.7 Modelo resultante de la Transformación de un modelo UML2 a un modelo UML 2 del Paquete Entities ... 132
Figura 5.8 Perfil Association aplicado a la propiedad solicitudReparacionItem ... 132
Figura 5.9 Componentes JavaEE del Paquete Business generados en la Segunda Transformación ... 133
Figura 5.10 Detalle de los Componentes de la Clase SectorServiceSessionBean ... 134
Figura 5.11 Estructura de elementos Java EE generados por la transformación Acceleo ... 135
Figura 5.12 Ejemplo de Código Fuente Generado para Clase Stateless ... 136
Figura 5.13 Ejemplo de Código Fuente Generado para Clase Entity ... 136
Figura 7.1 Elementos del núcleo de BPMN 2.0 ... 149
Figura 7.2 Elementos del núcleo de BPMN 2.0 ... 150
Figura 7.3 Ejemplo de Definitions ... 151
Figura 7.4 Clases del paquete Foundations... 152
Figura 7.5 Clases del paquete Collaboration ... 153
Figura 7.6 Clases del paquete Collaboration ... 154
Figura 7.7 Clases del paquete Process ... 155
Figura 7.8 Asociaciones y atributos de un modelo de proceso ... 156
Figura 7.9 Ejemplo de elemento Process de tipo ejecutable ... 157
Figura 7.10 Diagrama de clases para el elemento Task. ... 158
Figura 7.11 Diagrama de clases para el elemento Service Task ... 159
Figura 7.12 Ejemplo de elemento Service Task. ... 159
IX
Figura 7.14 Ejemplo de DataStore ... 161
Figura 7.15 Diagrama de clases para el elemento Lane... 162
Figura 7.16 Ejemplo de LaneSet y Lane ... 163
Figura 7.17 Paquetes de Infrastructure ... 165
Figura 7.18 Paquete Core y su relación con MOF y UML ... 166
Figura 7.19 Paquetes de InfrastructureLibrary ... 166
Figura 7.20 Elementos del Diagrama de Clases del Package Basic tomado de [17] ... 168
Figura 7.21 Elementos del Diagrama de Paquetes tomado de [17] ... 168
Figura 7.22 Elemento Class y sus relaciones tomado de [61] ... 169
Figura 7.23 Elemento Operation y sus relaciones tomado de [61] ... 171
Figura 7.24 Elemento Association y sus relaciones tomado de [61] ... 173
Figura 7.25 Elemento package y sus relaciones tomado de [61] ... 174
Figura 7.26 Paquetes de InfrastructureLibrary ... 174
Figura 7.27 Elemento Interface y sus relaciones tomado de [61]... 176
Figura 7.28 Dependencia entre paquetes Profiles ... 177
Figura 7.29 Los elementos del paquete Profiles, tomado de [61] ... 177
Figura 7.30 Clasificación RAC ... 179
Figura 7.31 Esquema general del proceso de RAC ... 179
Figura 7.32 Diagrama Técnico BPMN2 del caso de estudio: Sistema de Guardia Hospitalario ... 180
Figura 7.33 Diagrama BPMN 2 con visualizador de formato XMI ... 181
Figura 7.34 Componentes generados en la primera transformación ... 182
Figura 7.35 Parte del modelo generado en la primera Transformación en el Paquete entities. Versión Diagrama UML 2. ... 183
Figura 7.36 Parte del modelo Generado en la primera Transformación en el Paquete entities. Versión XMI. 183 Figura 7.37 Modelo Generado en la primera Transformación en el Paquete Business. Versión XMI. ... 184
Figura 7.38 Modelo resultante de la Transformación de un modelo UML2 a un modelo UML 2 del Paquete Entities ... 185
Figura 7.39 Perfil Association aplicado a la propiedad encuentroMedicoItem ... 186
Figura 7.40 Componentes JavaEE del Paquete Business generados en la Segunda Transformación ... 186
Figura 7.41 Detalle de los Componentes de la Clase MedicoServiceSessionBean ... 187
Figura 7.42 Estructura de elementos Java EE generados por la transformación Acceleo ... 188
Figura 7.43 Ejemplo de Código Fuente Generado para Clase Stateless ... 189
Figura 7.44 Ejemplo de Código Fuente Generado para Clase Entity ... 189
X
Índice de Tablas
Tabla 3.1 Resumen de las principales propuestas para las transformaciones de CIM a PIM ... 66
Tabla 3.2 Características de la Propuesta ... 69
Tabla 4.1 Descripción de Elementos del Perfil Independiente de la Tecnología ... 79
Tabla 4.2 Generación de model UML2 y Paquetes business y entities. Vista textual. ... 79
Tabla 4.3 Regla de transformación de un Proceso BPMN 2.0 a una Clase UML 2.Vista textual... 81
Tabla 4.4 Regla de transformación de un elemento Lane BPMN 2.0 a una Clase UML 2. Vista textual. ... 83
Tabla 4.5 Transformación de ServiceTask BPMN 2 a Operation UML 2. Vista textual. ... 84
Tabla 4.6 Transformación de DataStore BPMN 2 a Operaciones UML 2. Vista textual. ... 86
Tabla 4.7 Transformación de un modelo BPMN 2.0 a Elementos Generales UML2. Vista textual. ... 88
Tabla 4.8 Transformación de un elemento DataStore BPMN 2 a elementos UML2. Vista Textual. ... 89
Tabla 4.9 Regla de transformación de un elemento Lane BPMN 2.0 a una Clase UML 2. Vista textual. ... 90
Tabla 4.10 Regla de transformación de un elemento Participant BPMN 2.0 a una Clase UML 2. Vista textual. ... 92
Tabla 4.11 Transformación de elementos en el paquete business.Vista textual. ... 100
Tabla 4.12 Transformación de Clases del Paquete entities.Vista textual. ... 104
Tabla 5.1 Casos de Estudio ... 125
Tabla 6.1 Resumen de Resultados ... 143
Tabla 7.1 Atributos para elemento Definiciones (Definitions) ... 150
Tabla 7.2 Atributos Principales de Collaboration ... 153
Tabla 7.3 Atributos Principales de Message Flow... 154
Tabla 7.4 Atributos Principales del elemento Process ... 156
Tabla 7.5 Atributos Principales del elemento Service Task ... 159
Tabla 7.6 Atributos Principales del elemento Script Task ... 160
Tabla 7.7 Atributos Principales del elemento LaneSet ... 162
1
1. Introducción
En este capítulo se presenta una descripción de la motivación y justificación de la propuesta presentada en esta tesis, la hipótesis de trabajo y objetivos, así como la metodología de trabajo seguida y, finalmente, la organización del contenido de este documento de tesis.
1.1 Motivación
El Business Process Model Notation 2.0 (BPMN 2) [1] es un estándar de la OMG [2] cuyo objetivo es proveer una notación fácil de entender y comunicar entre usuarios que van desde analistas de negocios hasta ingenieros de software. Es ampliamente adoptada por las empresas para los propósitos de modelado de los procesos básicos, análisis detallado de performance, especificación de requerimientos y diseño ejecutable.
Un problema común del modelado de procesos de negocio es el desafío de lograr la consistencia con los sistemas informáticos. Una forma de lograr esta consistencia es utilizando un diseño de procesos siguiendo una estructura con distintos niveles de abstracción que va desde el modelado de procesos a nivel descriptivo a un nivel técnico. A partir del modelo de procesos a nivel técnico es necesario obtener el software que permita automatizar lo más eficaz y eficientemente posible los procesos de la organización. Esto es de vital importancia teniendo en cuenta el dinamismo de las organizaciones modernas donde rediseñar, mejorar o introducir nuevos procesos es algo que ocurre con frecuencia.
Para la automatización de procesos de negocio especificados a nivel técnico o ejecutable surge como alternativa fundamental la Arquitectura Dirigida por Modelos (MDA) [3]. La transformación de modelos es una parte esencial de MDA. Permite la transformación de un modelo origen a un modelo destino utilizando estándares.
En este trabajo se hace una propuesta tendiente a lograr el objetivo de mantener la articulación entre modelos de procesos técnicos y el software que permite automatizarlos. Para lograr esto mediante la metodología MDA, se partirá de un modelo BPMN 2.0 ejecutable y se demostrará que mediante transformaciones automáticas o semi-automáticas se pueden obtener los componentes de la arquitectura lógica de una aplicación Enterprise Java.
2
1.2 Objetivos de la Tesis
Las organizaciones de la actualidad están en permanente cambio siendo una necesidad tener automatizados, total o parcialmente, sus procesos de negocio. Por esta razón, es imprescindible mantener la articulación o alineamiento entre los procesos del negocio y los sistemas informáticos.
Se identifican dos problemas a resolver:
Mejorar la automatización de la evolución de modelos abstractos de procesos a plataformas de implementación específicas.
Lograr la consistencia entre procesos del negocio ejecutables, definidos mediante el estándar BPMN 2, y el software que automatiza a estos procesos.
En base a la definición de los problemas se plantea la siguiente hipótesis de trabajo:
“¿Es factible transformar en forma automática y/o semiautomática modelos de procesos ejecutables definidos con el estándar BPMN 2.0 a componentes Java EE?”. En base a la hipótesis planteada el objetivo general de esta tesis es:
“Transformar en forma automática y/o semiautomática modelos de procesos ejecutables definidos con el estándar BPMN 2.0 a componentes Java EE”.
Para lograr esto es necesario el desarrollo de perfiles, transformaciones en el marco de MDA y un método de trabajo. Entonces, los objetivos específicos se definen como:
Diseñar perfiles UML 2, independientes y específicos de la plataforma.
Desarrollar la transformación de un modelo técnico BPMN 2 a un diagrama de clases UML 2 [5] (modelo independiente de la plataforma).
Desarrollar la transformación del diagrama UML 2 obtenido en el punto anterior a un diagrama UML 2 con estereotipos del perfil EJB 3.1-JPA 2 [6][7](Modelo dependiente de la plataforma).
Desarrollar la transformación del último modelo a código fuente java que compone los elementos de la capa del negocio Java EE [8].
Diseñar un método de trabajo para el desarrollo y validación de las transformaciones.
En el marco de la metodología MDA, se realizarán transformaciones para lograr los objetivos definidos a partir de la hipótesis planteada. Las dos primeras transformaciones se realizan con el lenguaje Relations que forma parte de Query/Views/Transformations (QVT) [4] y la última con la herramienta Acceleo [9] que se basa en el lenguaje MTL definido en
3
la especificación de la OMG MOFM2T [10]. En las transformaciones desarrolladas se aplican perfiles UML2 para facilitar el proceso de transformación automático de un modelo origen a un modelo destino con mayor nivel de detalle.
Los modelos producto de las transformaciones se validarán mediante casos de estudio que permitan obtener resultados que prueben la efectividad de la solución propuesta. En la sección siguiente se detalla el proceso de validación de las transformaciones.
1.3 Metodología de Trabajo
La metodología de trabajo diseñada y explicada en esta sección se basa en algunos de los elementos planteados en los siguientes trabajos: [11], [12] y [13].
En base a los objetivos planteados para el desarrollo de la tesis se estudian todos los temas teóricos necesarios. Como resultado se elabora el capítulo 2 “Conceptos Básicos”. A partir de estos conceptos básicos se elabora el estado del arte con la finalidad de determinar el alcance del problema y el estado de las soluciones actuales propuestas.
Posteriormente se realiza el estudio y prueba de los metamodelos basados en el estándar de la OMG: BPMN 2 y UML 2. Como parte de las contribuciones realizadas se desarrollan los siguientes perfiles UML2:
Perfil Independiente de la Plataforma Perfil Perfil Ejb 3.1-Web Services Perfil JPA 2
En base a lo anterior se seguirá un proceso continuo, iterativo e incremental que pasa por varias etapas de refinamiento y validación. El resultado de este proceso es el desarrollo de transformaciones QVT y la validación de las mismas. Estas transformaciones permiten obtener modelos UML2 y componentes JavaEE alineados a un modelo de procesos técnico BPMN 2.
En la figura 1.1, se observan los pasos de una iteración para obtener una transformación. Este flujo de trabajo representa la parte principal del método de trabajo diseñado para lograr los objetivos propuestos. Muestra en general como, en base a un modelo origen, se van haciendo experimentos que son validados en forma cuantitativa y cualitativa hasta llegar a la transformación deseada. El flujo de trabajo se compone por etapas que a la vez incluyen tareas que varían según la transformación elegida.
Cada iteración comienza con el diseño de un modelo BPMN 2 abstracto o basado en el proceso real de una empresa del medio. Luego se crea la transformación QVT del modelo BPMN 2 a un modelo UML 2 con perfil independiente de la plataforma. Una vez obtenido el modelo UML2 se contrasta con el modelo UML2 realizado por un experto lo cual constituye la etapa de validación. Si el modelo generado coincide totalmente con el modelo del experto se pasa a la siguiente transformación, sino, se modifica la transformación. La siguiente transformación sigue un flujo similar pero esta vez parte del modelo UML2 con
4
perfil independiente de la plataforma. En el capítulo 5 se explica en detalle cada etapa de las iteraciones realizadas en el contexto del método de trabajo elegido para el desarrollo de la tesis.
Figura 1.1 Pasos de una Iteración para obtener una Transformación
Las iteraciones son aplicadas primero en experimentos de laboratorio controlados donde se utilizan distintos modelos BPMN2 genéricos. Luego se prueban las transformaciones con dos casos de estudio basados y aplicados en procesos reales de un organismo de salud pública. El resultado exitoso de lo anterior permite verificar la hipótesis planteada.
Dada su importancia, a continuación se explica la etapa de validar la transformación.
Validar la Transformación
El proceso de validación de las transformaciones es una etapa crucial que forma parte de las iteraciones que se llevaron a cabo para lograr las transformaciones. Las transformaciones QVT nos permiten obtener un modelo destino en base a un modelo origen.
Se trabaja sobre el supuesto que las transformaciones QVT generan un modelo o código fuente. Este modelo o código fuente se puede pensar como una estimación del modelo o código fuente que podrían haber elaborado ingenieros de software. Entonces para el desarrollo de las transformaciones se tienen en cuenta el supuesto que se van a estimar con cierto grado de certeza los elementos que van a formar parte del modelo destino.
5
Siguiendo con la explicación anterior, las transformaciones tienen en cuenta características del o los elementos origen para usarlos en la creación del o los elementos destino. Se puede pensar que el producto de las transformaciones QVT son predicciones o estimaciones basadas en supuestos sobre las relaciones entre los elementos del modelo origen y destino. Por ejemplo, una transformación puede estimar que el elemento origen Datastore de un modelo BPMN 2, posiblemente va ser pensado por un diseñador UML como una clase persistente. Un modelo o código fuente elaborado por expertos se basa entre otros en: heurísticas, reglas, estilos, estándares, patrones, etc…
Basados en lo anterior se propone como método de validación la comparación del modelo o código fuente generado por las transformaciones con el modelo real propuesto por expertos. En el caso de mantenimiento explicado en el capítulo 5, se utiliza para probar los elementos generados y el código fuente de un desarrollo existente.
En la figura 1.2, se puede observar que los modelos generados por las transformaciones son comparados con los modelos generado por expertos.
Figura 1.2 Elementos Involucrados en la verificación de las transformaciones
El método de prueba planteado permite obtener una medida cuantitativa del funcionamiento del modelo y sirve para determinar si la transformación está funcionando de acuerdo a los objetivos planteados. En este trabajo de tesis la prueba de coincidencia entre los modelos se hace en forma manual pero es factible su automatización.
Para la comparación automática hay que tener en cuenta que los nombres de los elementos de los modelos que define el diseñador pueden variar de los que genera la transformación. Para esto se puede implementar comparaciones que implementen algoritmos como Jaro-Winkler, para medir el grado de similitud entre el nombre del elemento del modelo origen y el nombre del elemento destino.
Evaluación de la validez del modelo destino
También hay que tener en cuenta las características que tiene que tener el modelo definido por expertos. Debe considerarse que los expertos definan el modelo siguiendo la arquitectura general utilizada, ciertos patrones de diseño, estilos y buenas prácticas de de diseño y programación. Esto se debe hacer para que la comparación sea lo más objetiva posible.
6
1.4 Estructura de la Tesis
El presente documento, que corresponde al informe del trabajo de tesis de maestría realizado, se organiza de la siguiente manera:
En el primer capítulo se presenta una breve descripción de la motivación de la propuesta presentada en esta tesis, así como la metodología de trabajo seguida, los objetivos, aportes y publicaciones y, finalmente, la organización del contenido de este documento de tesis. En el segundo capítulo se describe una revisión de los conceptos básicos necesarios para poder realizar posteriormente el estado del arte y elaborar las transformaciones que son objetivo de esta tesis.
En el tercer capítulo, se presenta el estado del arte, un análisis de la investigación actual sobre los temas relacionados con la propuesta de esta Tesis de Maestría: transformaciones MDA desde modelos de procesos del negocio a una plataforma tecnológica. Se muestran los trabajos relacionados haciendo hincapié en: estándares, lenguajes, métodos y herramientas utilizadas en nuestro trabajo.
En el cuarto capítulo, se detallan los principales aportes de la tesis, la propuesta de transformaciones y perfiles, la cual incluye los perfiles UML2 diseñados y las tres transformaciones desarrolladas con el estándar QVT.
En el quinto capítulo, se presenta por un lado la aplicación del método de trabajo y por otro lado un caso de estudio sobre un caso real consistente en la implementación de un sistema de mantenimiento correctivo. En el caso de estudio se aplican las transformaciones propuestas para generar un prototipo formado por los componentes de código fuente JavaEE.
Finalmente, en el sexto capítulo se muestran las conclusiones y resultados obtenidos en la tesis, así como las futuras líneas de investigación.
7
2. Conceptos Básicos
Introducción
2.1 Arquitectura Dirigida por Modelos
El Object Management Group (OMG) [2] es una organización internacional sin fines de lucro. Creado 1998 se estructura en forma de consorcio donde participan cientos de organizaciones como vendedores, desarrolladores de aplicaciones software y usuarios finales.
Los objetivos principales de la OMG son el establecimiento de especificaciones que permitan el desarrollo de software basado en tecnología orientada a objetos en entornos distribuidos y heterogéneos, donde estén presentes características como: reusabilidad, portabilidad e interoperabilidad.
La Arquitectura Dirigida por Modelos (Model Driven Architecture-MDA) [3] es un framework para el desarrollo de software definido por el OMG. MDA se basa en la definición de modelos formales y transformaciones automáticas de un modelo a otro de forma de lograr beneficios en aspectos como la productividad, la portabilidad, la interoperabilidad y el mantenimiento.
Con MDA es posible definir una vez la especificación funcional del sistema mediante un modelo independiente de la plataforma para luego mediante transformaciones obtener modelos dependientes de plataformas tecnológicas. Esto permite que las organizaciones conserven la especificación funcional de los sistemas y facilitar la integración con nuevas tecnologías que brinden beneficios adicionales a las aplicaciones actuales.
MDA define tres niveles conceptuales de modelado con distintos niveles de abstracción: El primero de ellos especifica los requisitos del sistema en un modelo independiente
de la Computación (Computation Independent Model-CIM), este brinda información acerca del dominio de la aplicación y es el que sirve de nexo entre los especialistas del negocio y los desarrolladores de software.
El segundo nivel muestra al sistema como un modelo independiente de la Plataforma (Plataform Independent Model-PIM), se utiliza para modelar la funcionalidad y estructura del sistema sin detallar los aspectos tecnológicos de la plataforma donde se implementará.
Por último el tercer nivel, tiene por objetivo obtener un modelo dependiente de la Plataforma (Plataform Specific Model-PSM) mediante transformaciones del modelo
8
del nivel anterior. Este modelo está compuesto por las especificaciones definidas en el nivel PIM con el agregado de los detalles de la plataforma elegida.
La transformación de modelos es una parte esencial de MDA. Desde un modelo CIM se puede obtener a través de transformaciones automáticas una implementación del sistema definido en el nivel PSM.
2.2 Metamodelos y Arquitectura MOF
Meta Object Facility (MOF) [4] es el lenguaje propuesto por la OMG para crear metamodelos. El uso del estándar MOF y el concepto de metamodelo es fundamental en MDA. Un metamodelo es un modelo que define el lenguaje para expresar un modelo. Es decir, que un metamodelo es un modelo que describe los elementos que puede utilizar un modelo. MOF describe una arquitectura basada en cuatro niveles de abstracción llamados M3, M2, M1 y M0. Cada capa se define como una instancia de la anterior.
2.2.1 Nivel M3 (Meta-metamodelo)
El lenguaje de la OMG del nivel M3 es el MOF. MOF es un lenguaje que permite definir lenguajes de modelado. Cada elemento del nivel M2 es una instancia de un elemento de M3, y cada elemento de M3 define elementos de M2. Por ejemplo, el metamodelo UML 2 [5] es una instancia de MOF.
2.2.2 Nivel M2 (Metamodelo)
El modelo que se encuentra en este nivel se llama metamodelo. Cada elemento del nivel M1 es una instancia de un elemento de M2. Un modelo UML 2 especificado en el nivel M1 es una instancia del metamodelo UML 2. Las entidades en este nivel podrían ser: Clase, Atributo y Asociación. Lenguajes como UML se han definido como instancias de MOF.
2.2.3 Nivel M1 (Modelo)
Los elementos que aparecen en este nivel son abstracciones o clasificaciones de las instancias del nivel M0. Cada elemento del nivel M0 será una instancia del nivel M1. En este nivel el desarrollador define los conceptos que luego forman parte del diagrama de clases del sistema de información. Un ejemplo de elemento de este nivel puede ser la clase Obra Social con atributos: código, nombre y descripción.
2.2.4 Nivel M0 (Instancias)
Los elementos de este nivel se refieren a las instancias concretas de los conceptos del nivel M1. Un ejemplo de elemento de este nivel puede ser el objeto obra social con nombre Obra Social de Empleados Públicos. En la figura 2.1, se observa un ejemplo de las cuatro capas de modelado MOF definidas por la OMG.
9
Figura 2.1 Ejemplo de arquitectura de 4 capas de modelado
2.3 Transformaciones con Query View Transformation (QVT)
Las transformaciones de modelos utilizando el estándar QVT-Relations se realizan en el contexto de la arquitectura de metamodelos MOF (Meta Object Facility). A continuación se explican: las transformaciones QVT, la relación con los niveles de modelados y los niveles MOF y los componentes de QVT-QVT-Relations.2.3.1 Transformaciones
Una transformación es la generación automática de un modelo destino en base a un modelo fuente utilizando un conjunto de reglas de transformación no ambiguas. Este conjunto de reglas de transformación es llamada definición de la transformación y describe como un modelo expresado en un lenguaje fuente puede ser transformado en un modelo de un lenguaje destino [14].
Las transformaciones permiten convertir los modelos situados en el nivel PIM en uno del nivel PSM y de este al código fuente. La figura 2.2 muestra un esquema del concepto de transformación de modelos en el ámbito de MDA y la relación entre los niveles de modelado PIM, PSM y los niveles MOF.
10
Figura 2.2 Relación entre PIM, PSM y los niveles MOF
Cada lenguaje de modelado extiende del Meta-metamodelo MOF. Un ejemplo de lenguaje de modelado puede ser UML 2. El lenguaje Origen y Destino pueden ser el mismo o distintos. Las reglas de transformación son definidas utilizando el metamodelo origen y destino. El modelo origen puede expresarse como por ejemplo con un diagrama de clases UML que puede estar representado como un modelo independiente de la plataforma (PIM). El modelo destino puede ser dependiente de la plataforma (PSM) y se obtiene mediante la aplicación de las reglas de transformación.
Como se observa en la Figura 2.2, una transformación de modelos toma como entrada un modelo Origen definido en base a un metamodelo origen y produce como salida un modelo Destino definido en base a un metamodelo destino.
La utilización de una herramienta como ATL [15] o Medini QVT [16] permite que la generación sea automática. Las transformaciones pueden ser definidas mediante reglas con un enfoque relacional u operacional, así como transformaciones utilizando grafos, entre otros enfoques.
2.3.2 QVT-QVT/Relations
El estándar definido por el OMG para la transformación de modelos cuyos metamodelos se basan en MOF es QVT. La especificación QVT del OMG está relacionada con las especificaciones: MOF 2.0 y Object Constraint Language 2.0 (OCL) [17]. El estándar está formado por tres componentes: consultas, vistas y transformaciones.
11
2.3.2.1 Consultas
Una consulta es una declaración que se aplica sobre el metamodelo fuente para obtener instancias de los elementos definidos en el metamodelo destino. El lenguaje que se utiliza para realizar las consultas es OCL. La figura 2.3, muestra un ejemplo:
-- Devuelve la primer ocurrencia del nombre del estereotipo
query getStereotype ( stName : String ) : uml::Stereotype
{
Stereotype.allInstances()->select
(x : uml::Stereotype | x.name = stName)->asSequence()->first() }
Figura 2.3 Ejemplo de consulta OCL 2.3.2.2 Vista
Una vista permite obtener como resultado una consulta a partir de un modelo base mediante la aplicación de una transformación. Las consultas pueden ser vistas como un tipo restringido de vistas bajo alguna condición.
2.3.2.3 Transformación
Como se muestra en la sección 2.3.1, una transformación genera un modelo destino utilizando como base un modelo origen. Se utilizan reglas de transformación que utilizan la definición de metamodelos origen y destino. Mediante un lenguaje transformación como QVT es posible generar automáticamente la transformación de un modelo al otro.
QVT soporta lenguajes declarativos e imperativos, la parte declarativa está formado por una arquitectura de dos niveles formados por QVT Relations y QVT Core. En la parte imperativa el lenguaje especificado es el Operational Mappings.
2.3.3 QVT Relations
QVT Relations está compuesto por un metamodelo y el lenguaje Relations que soporta pattern matching (coincidencia de patrones) de objetos complejos y templates (plantillas) de creación de objetos. La traza de los elementos de los modelos involucrados en las transformaciones son creados explícitamente.
2.3.3.1 QVT Core
Especifica un lenguaje declarativo de menor nivel de abstracción que Relations. Formado por un metamodelo y lenguaje Core basado en EMOF y OCL 2.0. No se crean clases de traza, hay que crearlas explícitamente.
12
Como analogía a la arquitectura del lenguaje java, el núcleo del lenguaje es como el Java Byte Code y la semántica Core es como la especificación del comportamiento de la Máquina Virtual de Java. El lenguaje de QVT Relations desempeña el papel del lenguaje Java, y la transformación de las relaciones a nivel central es como la especificación de un compilador de Java, que produce Byte Codes.
En la figura 2.4, se muestra la relación entre los metamodelos QVT. Se presentan dos formas de expresar las implementaciones imperativas de transformaciones, mediante los lenguajes Relations o Core.
Figura 2.4 Relación entre los metamodelos QVT 2.3.3.2 Operational Mapping
El lenguaje QVT Operational Mapping permite definir transformaciones utilizando un enfoque completo imperativo o permite complementar las transformaciones relacionales con operaciones imperativas para la aplicación de las relaciones. Se trata de un lenguaje procedural, definido en torno a un conjunto de extensiones del lenguaje OCL que utiliza características de lenguajes imperativos como: if, variables, loops, etc...
2.3.3.3 Black-box MOF Operation
No se trata de un lenguaje, sino de un mecanismo que permite enlazar código escrito en cualquier lenguaje. Para ello, se utiliza el lenguaje Relations para derivar una operación MOF de una transformación. Esta operación será el punto de enlace con el lenguaje deseado, que deberá definir la operación a ejecutar con la misma signatura, y soportar un enlace con la implementación de MOF que se esté utilizando.
Como analogía de la arquitectura Java, la posibilidad de invocar las implementaciones de Black-box MOF se puede considerar equivalente a llamar a la interfaz nativa de Java (JNI). Core y Relations permiten los siguientes escenarios de ejecución:
Transformaciones Check-only. Transformaciones unidireccionales. Transformaciones bi-direccionales.
13
Habilidad para establecer relaciones entre modelos preexistentes, ya sean desarrollados manualmente, mediante cualquier otra herramienta o mecanismo. Actualizaciones incrementales en cualquier dirección.
Habilidad para crear y eliminar objetos y valores, además de poder especificar qué objetos y qué valores deben ser modificados.
2.3.3.4 El lenguaje Relations
Es una especificación declarativa de las relaciones entre modelos MOF. El lenguaje Relations soporta la coincidencia de patrones de objeto complejos y crea implícitamente trazas de clases y sus instancias para registrar que ocurrió durante la ejecución de una transformación.
Una transformación especifica restricciones que deben cumplir los modelos candidatos. Compuesta por dos o más dominios, una cláusula when y una cláusula where que permiten definir las pre y post condiciones.
2.3.3.5 Transformación y Tipos de Modelos
La transformación entre dos modelos se representa mediante un conjunto de relaciones que deben ser satisfechas para poder crear la transformación. Un modelo debe estar definido en base a un metamodelo. Por ejemplo un modelo UML está definido en base a su respectivo metamodelo UML.
En el ejemplo de la figura 2.5, se muestra la declaración con nombre bpmnuml que tiene como modelo origen y destino a los modelos: bpmn y uml. El modelo bpmn declara al metamodelo Bpmn2 como metamodelo y el modelo uml declara al metamodelo Uml2. Una transformación puede ser invocada para verificar la consistencia entre dos modelos o para modificar un modelo de forma tal de forzar la consistencia.
transformation bpmnuml(bpmn:Bpmn2, uml:Uml2) {
Figura 2.5 Declaración de una transformación en QVT 2.3.3.6 Relaciones y Dominios
Una relación declara restricciones que deben ser cumplidas entre dos modelos. Una relación es definida por dos o más dominios y las cláusulas when y where. Un dominio puede verse como una variable de un determinado tipo de modelo y se describe mediante patrones.
En la figura 2.6, la relación Package2Schema es definida por los dominios “p” y “s”. Éstas son variables del tipo del metamodelo uml y rdbms respectivamente y expresan relaciones que deben mantenerse entre UMLPackage y Schema.
14
Cada dominio declara un patrón llamado plantilla de objeto para encontrar, crear y modificar package y schemas en los modelos pasados para la transformación. Cualquier package en un modelo de entrada que tenga un atributo nombre es vinculado a la variable de plantilla “p” y transformado al schema vinculado a “s”, donde el nombre del schema es modificado al que tiene el package. Es decir, cada dominio especifica un patrón: un package con un nombre y un schema con un nombre. La propiedad nombre está siendo vinculada a la misma variable pn implicando que deberían tener el mismo nombre.
top relation Package2Schema
{
pn: String;
domain uml p:UMLPackage{ nombre = pn }; domain rdbms s:Schema { nombre =pn }; }
Figura 2.6 Ejemplo de dominios 2.3.3.7 Dirección de la Ejecución de las Transformaciones
Una transformación se ejecuta en una dirección particular mediante la selección de uno de los modelos candidatos como objetivo o destino. El modelo destino puede estar vacío, o puede contener elementos del modelo existente y que están relacionados por la transformación. Según su semántica, se puede establecer que una relación sea unidireccional o bidireccional.
Para especificar la dirección de la relación un dominio puede ser declarado como checkonly o enforce. La palabra clave checkonly verifica que los modelos sean equivalentes de acuerdo a las restricciones. Cuando la transformación se aplica en la dirección de checkonly solo se comprueba si existe una coincidencia válida con el modelo que satisfaga la relación. En el caso de enforce comprueba los modelos a procesar, y si no son equivalentes de acuerdo a las reglas establecidas, se realizan los cambios necesarios. Cuando la transformación se ejecuta en la dirección de enforce, si la comprobación falla, el modelo destino se modifica de modo que se satisface la relación.
En base al ejemplo de la figura 2.7, se pueden considerar los siguientes escenarios:
Si ejecutamos una transformación en la dirección de uml y existe un schema en el rdbms el cual no tiene el correspondiente package con el mismo nombre en uml, sólo se informa como una inconsistencia, el package no se crea porque el dominio uml no está declarado como enforce sino como checked.
Si ejecutamos una transformación en la dirección de uml por cada package en el modelo uml la relación verifica si existe un schema con el mismo nombre en el
15
modelo rdbms. Si este no existe, un nuevo schema es creado con el nombre del package.
Se puede dar una variación en el escenario anterior. Si ejecutamos una transformación en la dirección de uml y existe un schema con el atributo nombre pero no existe el correspondiente package con el mismo nombre en uml, entonces el schema es eliminado del modelo rdbms.
La aplicación de estas reglas dependen del dominio que ha sido elegido como destino. En los casos anteriores el dominio elegido como destino es rdbms. Es decir, según sea la dirección que se define mediante enforce va depender el escenario de ejecución y por lo tanto las operaciones de creación, modificación y eliminación que se lleven a cabo sobre el modelo destino.
top relation Package2Schema
{
pn: String;
checkonly domain uml p:UMLPackage{ nombre = pn
};
enforce domain rdbms s:Schema { nombre =pn
}; }
Figura 2.7 Ejemplo de clausulas checkonly y enforce 2.3.3.8 Clausulas when y where
Una relación se puede formar por las clausulas when y where para añadir restricciones a su ejecución. La cláusula when representa una precondición que debe ser cumplida para que la relación pueda ser evaluada. Por ejemplo, la figura 2.8, muestra la relación Class2Table. En la cláusula when se indica que para realizar el mapeo de una clase a una tabla es necesario que el paquete al que pertenece la clase sea mapeado al schema que contiene la tabla, lo cual se realiza a través de la invocación a la relación Package2Schema. En resumen, una clase se puede transformar a una tabla sólo si el package correspondiente ha sido transformado a un schema.
La cláusula where es una postcondición que debe ser cumplida por todos los elementos de los modelos participantes de la relación, y éste puede restringir cualquiera de las variables en la relación y sus dominios. Por ejemplo, en la figura 2.8, se declara la cláusula where donde siempre que la relación ClassToTable se ejecute, la relación Attribute2Column también se debe realizar.
top relation Class2Table
{
theName: String; prefix: String;
16
checkonly domain uml c:UMLClass { name = theName,
owningPackage = p:UMLPackage {}, kind = UMLElementKind::Persistent };
enforce domain rdbms t:Table { name = theName,
schema = s:Schema {}, columns = cl:Column {
name = theName + '_PrimaryKeyColumn', type = 'NUMBER'
},
primaryKey = pk:PrimaryKey { name = prefix+ 'PrimaryKey'
constitutingColumnc = cl } }; when { Package2Schema(p, s); } where { prefix = theName + '_'; Attribute2Column(c, t, prefix); } }
Figura 2.8 Ejemplo de relación con las claúsulas when y where
Las cláusulas when y where pueden contener cualquier expresión del tipo OCL. Por ejemplo: prefix = theName + '_'. La invocación de relaciones permitirá que las relaciones complejas estén compuestas por relaciones más simples. En la cláusula when del ejemplo se indica que los atributos de la clase deben ser mapeados a columnas. Llamando a la relación Attribute2Column; ésta última a su vez realiza la invocación de otros mapeos.
2.3.3.9 Relaciones Top-level
La relaciones pueden ser definidas en dos niveles de complejidad anteponiendo o no la cláusula Top a la relación. Por ejemplo, en la figura 2.8, se puede observar que la relación Class2Table se encuentra al nivel top, a diferencia de attribute2Column.
Para que se ejecute una transformación se requiere que las relaciones se encuentren al nivel top y todas se satisfagan, mientras que las que no se encuentren en dicho nivel sólo se llevan a cabo cuando son invocadas directa o transitivamente a través de las cláusulas where y when.
2.3.3.10 Pattern Matching
La ejecución de una transformación implica que todas las relaciones necesarias sean invocadas para obtener el modelo destino a partir del modelo origen.
17
Cada relación tiene dos o más dominios. Cada dominio puede tener una expresión de plantilla de objetos que permite la coincidencia de patrones mediante su comparación con los elementos del modelo objetivo que se va a utilizar en la transformación.
Por ejemplo, para la expresión de la figura 2.9, relacionada con el dominio uml se define una expresión de plantilla de objeto. Esta se utiliza para comparar el patrón en el modelo utilizado. En el caso que el modelo contenga un elemento package con atributo nombre, existirá coincidencia de patrones y se ejecutará enforce generando un schema con nombre pn.
Figura 2.9 Ejemplo de coincidencia de patrones (pattern matching)
2.3.3.11 Clave
Para no crear duplicados por ejemplo cuando se hace una segunda transformación y ya existen elementos del modelo destino creado, es necesario utilizar un identificador de los elementos existentes. QVT-Relations utiliza el concepto clave(Key) , que define un conjunto de propiedades de una clase que identifican de forma exclusiva una instancia de objeto de la clase en un modelo. Una clase puede tener varias claves (como en bases de datos relacionales).
En la figura 2.10, se puede observar un ejemplo de utilización de clave en QVT Relation, donde se indica que una tabla está identificada por su name y schema.
transformation umlToRdbms(uml:SimpleUML, rdbms:SimpleRDBMS)
{
key Table {schema, name};
}
Figura 2.10 Ejemplo de Clave
2.3.4 Herramienta Medini-QVT
Para implementar las transformaciones modelo a modelo de la propuesta de la presente tesis se utiliza como herramienta el motor de transformaciones Medini-QVT. El motivo de la elección es que es una herramienta madura compatible con los estándares QVT y OCL, siendo una de las principales implementaciones del lenguaje QVT-Relations. Además cuenta con gran aceptación de la comunidad MDA y gran cantidad de referencias en papers, tesis e implementaciones como casos de éxito.
18
Medini QVT es un conjunto de herramientas para la generación de transformaciones modelo a modelo desarrollada por ikv++ technologies [26]. El código fuente está liberado bajo la licencia de código abierto EPL (Eclipse Public License v 1.0). La última versión estable del producto es la 1.6 estando disponible la versión 1.7 RC (Candidata a definitiva). Funciona integrado sobre el entorno de desarrollo Eclipse mediante la implementación de diversos plugin permitiendo la ejecución de transformaciones QVT especificadas con la sintaxis del lenguaje Relations. Solo el motor de ejecución de transformaciones es público y de código abierto. La documentación que brinda en su web es completa y está compuesta por tutoriales y videos.
Las principales características con las que cuenta son las siguientes: Se basa en EMF como entorno de modelado y metamodelado.
La ejecución de transformaciones QVT se expresan en la sintaxis concreta textual del lenguaje QVT-Relations
Tiene un editor con resaltado y completado de código. Un editor de código con asistencia y un depurador de relaciones.
Soporta el manejo de trazas. Depurador para trazar la ejecución de transformaciones paso a paso a través de las reglas.
Implementa el concepto de clave (key) del lenguaje QVT. Permite las actualizaciones incrementales.
Permite transformaciones con n-dominios participantes.
Habilita la creación de Transformaciones bidireccionales (cuando la especificación de las relaciones lo permita).
Permite chequeo sintáctico y semántico de la transformación Permite la posibilidad de integrarse dentro de una aplicación.
2.3.5 Herramienta Acceleo
Para la transformación del modelo UML 2 con perfiles a código java EE [8] se utiliza como herramienta Acceleo [9]. Está herramienta puede ser útil porque dispone de dos módulos con licencia EPL v.1.0 que permiten la generación de código UML con perfiles a java EE. Los módulos pueden servir en parte para la generación MDA de un PSM a código fuente. La especificación MOF Model to Text Transformation Language (MOFM2T) [10] definida por el OMG trata de cómo transformar texto a partir de modelos como UML, MOF o EMF. El texto puede representar el código fuente de un lenguaje de programación como java o ruby. El enfoque en el que se basa el estándar está basado en plantillas, el código fuente se genera a partir de la definición de un conjunto de plantillas parametrizadas con los
19
elementos del modelo. Acceleo es una herramienta que implementa la especificación MOFM2T.
La definición de la transformación se estructura por medio de módulos. Dentro del módulo se pueden especificar: plantillas y consultas. Se puede usar OCL para realizar consultas sobre los modelos de entrada.
Cuando se ha especificado el metamodelo y el modelo de entrada, se debe indicar las plantillas utilizadas en el proceso de generación. Luego se almacena la cadena indicando su nombre y la ubicación donde se encuentra.
El proceso de transformación empieza con la ejecución de una de las cadenas de generación creadas. Esto se logra usando la función ‘Launch’ sobre la cadena de generación. El archivo producto de la transformación será generado en el formato que se haya indicado y guardado en la dirección establecida.
Las principales características con las que cuenta son las siguientes:
Permite la generación de código basada en plantillas que representan reglas de transformación entre un modelo y el código fuente.
Se integra con el ambiente de Eclipse y el framework de EMF.
Posibilita la navegación por los elementos de cualquier modelo que siga los estándares de EMF (XMI).
Administra la sincronización entre el código y el modelo. Permite la generación incremental de código.
Facilita el mantenimiento y actualización de todas las plantillas.
Admite el coloreado sintáctico de las plantillas así como detección de errores basada en el metamodelo.
Permite la previsualización del código.
2.3.5.1 Componentes principales
Los componentes principales de Acceleo son módulos, plantillas y consultas.
Módulo
Un módulo es un archivo con extensión .mtl que contiene plantillas para la generación del código y puede incluir consultas para extraer información de los modelos.
La declaración del módulo se hace como en la figura 2.11:
20
Figura 2.11 Declaración de módulo
Un ejemplo de la declaración de un módulo se puede observar en la figura 2.12. [module generate('http://www.eclipse.org/uml2/4.0.0/UML')]
Figura 2.12 Ejemplo de módulo
Se puede reemplazar el comportamiento de otro módulo extendiéndolo y reemplazando alguna de sus plantillas. Desde un módulo se puede invocar una plantilla. Un módulo depende generalmente de otros módulos para su ejecución y se define mediante la declaración import, que puede importar otros módulos para acceder a las plantillas públicas y protegidas. La sintaxis se muestra en la figura 2.13.
import qualified::name::of::imported::module
Figura 2.13 Declaración de import
En la figura 2.14, se muestra un ejemplo de la declaración import.
[import or::eclipse::acceleo::module::sample::requests::request / /]
Figura 2.14 Ejemplo de import Plantilla (templates)
Las plantillas son un conjunto de instrucciones para generar texto. Están delimitadas por las etiquetas. En la figura 2.15, se puede ver un ejemplo.
[template...][/template]
Figura 2.15 Declaración de plantilla
Se puede observar un ejemplo de plantilla en la figura 2.16. Esta plantilla genera la definición de una clase java en base a una clase UML.
[template public classToJava(c : Class)] class [c.name/] {
// Constructor [c.name/]() {} }
[/template]
Figura 2.16 Ejemplo de plantilla
La sintaxis ofrece un conjunto de instrucciones que permiten realizar ciclos, tomar decisiones y navegar por los elementos del modelo.
