Post on 27-Sep-2018
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
San Luis, Diciembre de 2015
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.
Muchas Gracias!!!
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 .................................................................................................................. 7
2.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
4.1 COMPONENTES DE LA TRANSFORMACIÓN ....................................................................................... 71
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
6.4 CONCLUSIONES FINALES.................................................................................................................. 146
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
9. SIGLAS ......................................................................................................................................... 238
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
Figura 2.49 Ejemplo de relación uno a uno ................................................................................................... 53
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
Figura 4.46 Código fuente de la relación ClassToSession. Vista QVT Relations. ......................................... 103
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
Figura 7.13 Diagrama de clases para el elemento Data Store ....................................................................... 161
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
Figura 7.45 Paquetes de Infrastructure ........................................................................................................ 212
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 Tabla 7.8 Atributos Principales del elemento Lane .................................................................................... 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:
[module <module_name>('metamodel_URI_1', 'metamodel_URI_2')]
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.
Consultas
21
Las consultas son utilizadas para extraer información de un modelo. Pueden regresar un
valor o un conjunto de valores. Se utiliza el lenguaje OCL mediante la etiqueta que se
muestra en la figura 2.17.
[query ... /]
Figura 2.17 Declaración de consulta
En el estándar MOFM2T de la OMG se define una consulta de la siguiente forma:
“Es una función que no tiene efectos secundarios y pertenece a un módulo. Una consulta
siempre debe producir el mismo resultado cada vez que es invocada con los mismos
argumentos. Su cuerpo está especificado por una expresión OCL” [17].
Un ejemplo de una consulta en OCL se puede observar en la figura 2.18.
[query public obtenerAtributosPublicos(c : Class) : Set(Property)= c.attribute->select(visibility=VisiblilityKind::public)
/]
Figura 2.18 Ejemplo de consulta
2.3.6 Perfiles UML
Los perfiles UML 2 se encuentran definidos en la Infraestructura de UML 2. Estos
contienen mecanismos que permite que las metaclases de los metamodelos existentes
puedan ser extendidos para adaptarlos a diferentes propósitos. En el presente trabajo se
utilizan los perfiles para poder disponer de terminología y vocabulario propio de la
plataforma de implementación Java EE.
UML 2 es un lenguaje de propósito general con constructores que pueden ser demasiado
genéricos y cuya semántica no permite modelar a dominios específicos. La OMG permite
extender el lenguaje UML 2 especializando algunos de sus conceptos y restringiendo otros,
pero respetando la semántica original de los elementos de UML 2 como clases, atributos y
asociaciones.
Un perfil UML 2 permite extender al lenguaje de modelado unificado (UML) permitiendo
modelar los conceptos de dominios particulares mediante el agregado de nuevos
constructores al metamodelo de UML 2.
Un Perfil se define en un paquete UML 2, estereotipado «profile», que extiende a un
metamodelo o a otro Perfil. Para definir perfiles se emplean básicamente tres mecanismos:
estereotipos (stereotypes), restricciones (constraints), y valores etiquetados (tagged values).
Los estereotipos permiten definir nuevos tipos de elementos de modelado en base a los ya
existentes en el metamodelo de UML 2. Están compuestos por un nombre y por conjunto
de elementos del metamodelo con los que puede establecer asociaciones. Se representan
gráficamente mediante cajas estereotipadas con el nombre entre comillas <<nombre –
estereotipo>>. También se puede representar con un icono asociado al estereotipo.
22
Las restricciones imponen condiciones sobre los elementos del metamodelo que deben
cumplir para que este bien formado. Las restricciones pueden ser asociadas a los
estereotipos. Pueden ser expresadas en cualquier lenguaje pero generalmente se expresan
mediante OCL. Gráficamente se representan como una cadena de caracteres entre llaves
junto al elemento al que está conectado por una relación de dependencia.
Un valor etiquetado es un meta-atributo adicional que se asocia a una metaclase del
metamodelo extendido por un perfil. Los valores etiquetados tienen un nombre y un tipo y
son asociados a un estereotipo específico. Gráficamente son especificados como atributos
de una clase que define el estereotipo.
Los mecanismos de extensión no permiten modificar los metamodelos existentes, sólo
añadirles elementos y restricciones, pero respetando su sintaxis y semántica original. Si
permiten adaptar un metamodelo utilizando estereotipos, restricciones y valores etiquetados
a un dominio o plataforma existente.
En la figura 2.19, se muestra un ejemplo de perfil UML 2 que contiene un estereotipo
llamado Entidad. Este estereotipo extiende a la clase UML 2 Class agregándole un atributo
id de tipo Integer. Agrega también una regla OCL que indica que el valor del atributo id
solo puede ser mayor que cero.
Figura 2.19 Ejemplo de Perfil
Para elaborar un perfil UML se puede utilizar una forma estructurada basada en la
propuesta de Fuentes-Fernández et al. [18]. Esta se resume en las siguientes etapas:
Definir u obtener un metamodelo de la plataforma o dominio de aplicación a
modelar con un perfil.
En base al metamodelo dentro del paquete «profile» se debe incluir un estereotipo
por cada uno de los elementos del metamodelo que se van a incluir en el Perfil.
Estos estereotipos deben tener el mismo nombre que los elementos del metamodelo,
estableciéndose de esta forma una relación entre el metamodelo y el Perfil.
Tener claro cuáles son los elementos del metamodelo de UML 2 que estamos
extendiendo sobre los que es posible aplicar un estereotipo. Ejemplo de tales
elementos son las clases, sus asociaciones, sus atributos, las operaciones, las
transiciones, los paquetes, etc. De esta forma cada estereotipo se aplicará a la
23
metaclase de UML 2 que se utilizó en el metamodelo del dominio para definir un
concepto o una relación.
Definir como valores etiquetados de los elementos del Perfil los atributos que
aparezcan en el metamodelo. Incluir la definición de sus tipos, y sus posibles
valores iniciales.
Definir las restricciones que forman parte del Perfil, a partir de las restricciones del
dominio. Por ejemplo, las multiplicidades de las asociaciones que aparecen en el
metamodelo del dominio, o las propias reglas de negocio de la aplicación deben
traducirse en la definición las correspondientes restricciones.
2.4 BPMN 2 (Business Process Modeling Notation 2)
El Business Process Model Notation 2.0 (BPMN 2) [1] es un estándar del OMG cuyo
objetivo es proveer de una notación fácil de entender y facilitar la comunicación 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. La BPMN
2.0 añade nuevos elementos de diseño orientado a la ejecución, ofreciendo una definición
teórica de lo que hace un modelo ejecutable [19]. La introducción de un metamodelo MOF
habilita al intercambio, interoperatividad y la ejecución de modelos. Uno de los objetivos
de la presente tesis es transformar de un modelo técnico BPMN 2.0 a un modelo de clases
UML utilizando la arquitectura dirigida por modelos y sus estándares relacionados.
2.4.1 Gestión de Procesos del Negocio (Business Process Management-
BPM)
Una organización genera un conjunto de servicios (o productos) dirigidos a un cliente. Para
lograr que dicho servicio (o producto) llegue al cliente las organizaciones ejecutan un
proceso.
Según la NTP-ISO 9000:2001 un proceso se define como: "conjunto de actividades
mutuamente relacionadas o que interactúan, las cuales transforman elementos de entrada en
resultados", y en el caso de un producto la misma norma lo define como "resultado de un
conjunto de actividades mutuamente relacionadas o que interactúan, las cuales transforman
entradas en salidas". Los insumos y productos terminados pueden ser tangibles e
intangibles.
BPM (Business Process Management) es un enfoque sistemático que tiene por objetivo
lograr la adaptación rápida a los cambios, mayor eficiencia y eficacia en el desarrollo de
procesos de la organización. En [20] aparece una definición que dice “es una disciplina de
gestión por procesos de negocios y de mejora continua apoyada fuertemente por
tecnologías de la información”. Si bien no hay un acuerdo acerca de la definición de BPM
tomamos la que abarca el uso de las tecnologías de la información para mejorar, innovar y
gestionar los procesos de modo de lograr los objetivos del negocio.
24
Las ventajas de utilizar BPM son:
Dirigir la estrategia empresarial vinculando la información de los procesos y
detectando variaciones para tomar decisiones a tiempo
Brindar la flexibilidad y agilidad para adaptarse a los cambios.
Mejorar y adecuar los procesos de los distintos sectores de la empresa.
Incorporar sistemas de información orientados a procesos de forma de abordar más
rápido el cambio.
Diseñar, simular y monitorear procesos de manera automática.
Obtener niveles más altos de calidad mediante la implantación de estándares como
ISO 9000.
2.4.1.1 Fases para implementar BPM
El ciclo BPM es una guía para orientar en el desarrollo de un proyecto BPM. De acuerdo a
[20] un proceso puede encontrarse en un estado diferente del ciclo, el cual comienza a partir
de dos posibles escenarios:
Un proceso actual que debe levantarse y documentarse y/o rediseñarse.
Se debe introducir un nuevo proceso no existente en la organización.
En la figura 2.20 y 2.21, se puede ver una representación del ciclo BPM según [20].
Figura 2.20 El ciclo de BPM
25
Los modelos de las figuras se diferencian en que el primer modelo (figura 2.20) separa la
fase de "Diseño as is" (situación actual) cuando se implementa técnicamente por primera
vez un proceso existente y cuando se toma la decisión de implementarlo sin incorporación
de mejoras. El otro modelo (figura 2.21) pasa siempre por una análisis de mejora, a pesar
de que posterior al análisis se tome la decisión de no incorporar ninguna mejora.
Figura 2.21 El ciclo de BPM
Descripción de las Fases
Levantamiento del Proceso: se debe recoger la información sobre cómo está
organizado el flujo de trabajo. Esto se realiza con la ayuda de técnicas de
moderación, talleres, entrevistas, recolección de documentación, etc. Para esto en el
proceso a levantar se debe:
Delimitar claramente los procesos anteriores o posteriores.
Describir los servicios que produce para los clientes y qué prioridad tiene desde
el punto de vista de los objetivos empresariales.
Representar tanto el flujo de trabajo como los roles que intervienen en cada uno
de los pasos, los recursos que se utilizan y los sistemas de información que lo
apoyan.
Documentación del Proceso: el conocimiento adquirido en la etapa de
levantamiento se documenta en un modelo de procesos que refleja la situación
actual. La documentación resultante comprende los diagramas BPMN, fichas de
descripción, y procedimientos que se utilizan para ejecutar el trabajo.
Análisis de Mejora: Teniendo como base la documentación del proceso en su estado
actual “AS IS”, se plantearán una serie de posibles escenarios que permitan definir
un modelo esperado o como debe ser “TO BE”
26
Monitoreo del Proceso: Las debilidades identificadas en la fase de "Análisis de
Mejora" o las desviaciones que muestra el "Monitoreo del Proceso" son por lo
general el punto de partida para un rediseño de procesos.
Implementación del Proceso: abarca tanto la implantación técnica como también las
adaptaciones organizacionales que se requieren. La gestión del cambio y la
estrategia de comunicación constituyen elementos fundamentales a considerar para
el éxito del proyecto. El modelo técnico en BPM se puede implementar por medio
una Suite de BPM (Business Process Management Suite, BPMS) o mediante un
desarrollo propio.
El resultado final de la implementación técnica del proceso en la situación actual (As is)
automatizado y documentado, corresponde con el modelo de proceso deseado (To be).
Teniendo en cuenta el ciclo BPM se puede deducir que un estándar de modelamiento de
procesos como BPMN es fundamental para llevar a cabo las fases de la BPM.
2.4.2 BPMS
Para la implementación técnica de BPM se utiliza un tipo de sistemas llamado Business
Process Management System (BPMS). Estos sistemas se especializan en la gestión de
procesos de negocio.
Las principales funcionalidades que incorpora un BPMS para la implementación de BPM
son:
Modelador gráfico de procesos de negocio.
Motor de procesos que permita ejecutar de forma automática los procesos
modelados gráficamente.
Entorno de administración para el control y gestión del estado de procesos y
usuarios.
Sistema de monitorización (BAM, Business Activity Monitoring) que permita
visualizar de forma gráfica los indicadores clave de rendimiento de los procesos
(KPI, Key Performance Indicators).
Modelador de Formularios para crear y dar forma a las pantallas de introducción /
visualización de datos que se mostrarán a los usuarios.
Entorno de simulación y análisis para detectar oportunidades de mejora de los
procesos de negocio por medio de escenarios probables (what-if).
Integración de aplicaciones que permita el intercambio ágil de información entre los
procesos y el resto de sistemas empresariales (ERP (Enterprise Resource Planning),
CRM (Customer Relationship Management), etc.).
27
2.4.3 BPMN Framework
En el marco de la mejora continua de las organizaciones surge la necesidad del rediseño,
mejora y creación de procesos teniendo en cuenta su desarrollo e implementación a través
de tecnologías de la información. 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. El BPMN-Framework [20], es un marco metodológico que contempla 4
niveles. En la figura 2.22, se representa el marco estructural, en este trabajo nos
concentramos en el nivel técnico.
Figura 2.22 Niveles de Abstracción del BPMN Framework
Nivel 1. Procesos Descriptivos
Se representa el flujo normal del proceso sin tener en cuenta los errores o casos de
excepción. Permite dar una vista del alcance del proyecto introduciendo a los participantes
del proyecto en él.
Nivel 2. Procesos Operacionales
Se incluye la lógica de los procesos con el mayor detalle posible con casos de excepción,
fallas e interrupciones que pueden ocurrir para pasarlo al siguiente nivel de
implementación.
Nivel 3. Modelo Técnico
El modelo técnico toma el resultado de la representación del modelo operacional y lo
adapta a un modelo ejecutable agregándole las características técnicas.
Nivel 3a: Utilizando BPMN 2.0 se puede especificar el modelo técnico para que sea
ejecutado directamente en un BPMS.
Nivel 3b: En el caso de no utilizar un BPMS la lógica de negocio tiene que ser desarrollada
en algún lenguaje de programación.
28
Nivel 4. Implementación
Este nivel es sólo necesario si no utilizamos un BPMS
Nivel 4 a. Utilizando un BPMS no es necesario elaborar una especificación para el
desarrollo.
Nivel 4b. Una vez que tenemos el modelo técnico del nivel 3 es necesario implementar
técnicamente el proceso en una plataforma. Los diagramas deben convertirse a una
especificación adecuada al ambiente de programación elegido.
2.4.4 Notación de BPMN 2.0
El objetivo principal de BPMN es proporcionar una notación estándar que sea fácilmente
comprensible por todos los participantes de los procesos del negocio. En los últimos años
BPMN ha sido adoptado por fabricantes y usuarios relacionados con BPM, herramientas de
modelado y BPMS.
El desarrollo de la versión 1.0 de BPMN fue realizada por el Notation Working Group
junto con la Business Process Management Initiative (BPMI). Estaba compuesto por 35
empresas de modelado, organizaciones y personas. El objetivo era lograr un acuerdo sobre
una única notación (en cuanto a representación gráfica) la cual pueda ser adoptada por
herramientas y personas. Otro objetivo era que permitiera generar procesos ejecutables por
un motor de procesos [19].
En el año 2004 fue publicada la especificación 1.0 de BPMN. Esta especificación fue
adoptada ampliamente por usuarios y empresas de modelado. En el año 2006 la
especificación 1.0 fue adoptada como un estándar de la OMG. En el año 2008, la OMG
publicó la versión 1.1 de BPMN. Posteriormente la OMG ha publicado la versión 1.1 (año
2008), la versión 1.2 (año 2009) y la última versión 2.0 en el año 2011. Esta última versión
se diferencia de las anteriores por:
Extiende hacia un modelo y una notación que incluye un meta modelo
Nuevos modelos y Diagramas : Conversación y Coreografía.
Extensión del modelo de Colaboración: Múltiples participantes y nuevo objeto de
mensajes.
Extensión de la tipología de actividades, eventos y Gateways: muchos nuevos tipos.
Definición de un metamodelo de intercambio: basado en diagramas de clases de
UML.
Reglas para la ejecución de diagramas.
29
2.4.4.2 Descripción de los Elementos Gráficos BPMN 2.0
Los modelos BPMN se expresan gráficamente mediante diagramas BPMN. Teniendo en
cuenta que el trabajo de tesis está centrado en el modelado técnico con BPMN a
continuación se describen los elementos gráficos necesarios para poder cumplir con el
objetivo.
Objetos de Flujo
Eventos (Event)
Un evento es algo que "sucede" en el curso de un proceso. Estos eventos afectan el flujo del
modelo y por lo general tienen una causa o un resultado [1]. De acuerdo con el momento en
que afectan al flujo, se dividen en tres tipos: inicio, intermedio y fin. Estos eventos se
pueden apreciar en la figura 2.23.
Elemento Descripción Notación
Inicio Representa el inicio de un
proceso
Intermedio Detiene el flujo hasta que
ocurra una condición o
dispara acciones de
excepción
Fin Indica cuando finaliza un
proceso
en ejecución
Figura 2.23 Tipos básicos de eventos
Algunos tipos de eventos de inicio se representan en la figura 2.24.
Elemento Descripción Notación
Evento de inicio de mensaje El proceso inicia cuando se
recibe un mensaje desde un
participante (externo).
Evento de inicio de
temporización
Una fecha-hora o un ciclo
de tiempo (ej: cada Lunes a
las
18:00hs) que cuando se
cumple dispara el comienzo
del proceso
Evento de inicio de
condición
El proceso inicia cuando una
condición de negocio se
cumple.
Figura 2.24 Algunos tipos de eventos de inicio
30
Los eventos intermedios sirven para definir que algo sucede entre el inicio y el fin de un
proceso. Pueden utilizarse dentro del flujo de secuencia o adjunto a una actividad para que
esta sea ejecutada una vez que éste se active. Los eventos intermedios se pueden observar
en la figura 2.25.
Elemento Descripción Notación
Evento intermedio de
mensaje
Un mensaje arriba desde un
participante (externo) y
dispara el evento. Esto causa
que el proceso continúe.
También usado para enviar
un mensaje a un
participante. Si es usado
para el manejo de
excepciones, cambiará el
flujo normal a uno de
excepción
Evento intermedio de
temporización
Una fecha-hora o un ciclo
de tiempo (ej: cada Lunes a
las 18:00hs) que cuando se
cumple dispara el evento.
En un flujo normal actúa
como mecanismo de
demora. En el manejo de
excepciones, cambiará el
flujo normal a un flujo de
excepción
Evento intermedio de
condición
Se utiliza para esperar que
una condición de negocio se
cumpla.
.
Evento intermedio de error Utilizado para el manejo de
errores. Sólo puede ser
adjuntado al límite de una
actividad. Éste captura un
error etiquetado o cualquier
error si un nombre no es
especificado
Figura 2.25 Algunos tipos de eventos Intermedios
Los tipos de eventos de fin, terminan el flujo de un proceso y por lo tanto no poseen flujos
de secuencia salientes. En la figura 2.26, se muestran dos de los más utilizados.
31
Elemento Descripción Notación
Evento de fin de mensaje Indica que un mensaje es
enviado a un participante
(externo)
cuando finaliza el proceso
Evento de fin de error Envía una excepción de
error al finalizar el flujo.
Figura 2.26 Algunos tipos de eventos de Fin
Actividades (Activity)
Representa algo realizado en un proceso. Consumen recursos. Pueden ser atómicas o
compuestas. Las actividades son atómicas cuando están representadas con el menor nivel
de detalle en el diagrama. Las actividades no atómicas son las compuestas, estas se pueden
expandir a niveles más bajos de detalle en un diagrama.
Elemento Descripción Notación
Tarea Una tarea es una actividad
simple que se utiliza cuando
el trabajo realizado dentro
del proceso no está definido
en un nivel más detallado.
Sub-Proceso Es una actividad compuesta
cuyo detalle se define como
un flujo de otras actividades.
Figura 2.27 Algunos tipos de Actividades
Marcadores de Tarea (Task Markers)
BPMN especifica marcadores para las tareas. Las tareas pueden tener una o dos de estas
marcas. En la figura 2.28, se pueden observar dos ejemplos de marcadores de tarea.
Elemento Descripción Notación
Loop Representa la ejecución
repetida de una tarea en
forma secuencial
Múltiple Instancia Representa la ejecución de
múltiples instancias de la
tarea
Figura 2.28 Algunos tipos demarcadores de tareas
Tipos de Tareas (Task Types)
32
Los tipos de tareas son fundamentales para poder vincular los modelos técnicos de procesos
del negocio con una plataforma tecnológica como Java EE. En este trabajo se utilizan los
elementos Tarea de servicio y Tarea de Script para realizar transformaciones a UML. En la
figura 2.29, se pueden observar los distintos tipos de tareas.
Elemento Descripción Notación
Tarea de Servicio Representa un servicio
automatizado provisto por
un servicio web o una
aplicación.
Tarea de Envío Representa el envío de un
mensaje a un participante
externo.
Cuando el mensaje fue
enviado, la tarea finaliza.
Tarea de Recepción Representa la espera del
arribo de un mensaje desde
un participante externo al
proceso. Cuando se recibe el
mensaje, la tarea es
finalizada.
Tarea de Usuario Una tarea donde una
persona ejecuta la tarea con
la asistencia de una
aplicación de software y
dicha tarea es planificada a
través del manejador de lista
de trabajos de un BPMS.
Tarea Manual Una tarea que es ejecutada
sin la asistencia de una
aplicación o BPMS Regla del Negocio La ejecución de una regla de
negocio por un motor de
reglas de negocio, enviando
la entrada a la máquina de
regla y obteniendo la salida
de la misma
Tarea de Script Un script ejecutado por una
máquina de proceso de un
BPMS. El script se define en
el lenguaje de script provisto
por el
33
BPMS
Figura 2.29 Tareas
Compuertas (Gateways)
Definen los tipos de comportamiento del flujo de secuencia de un proceso. Son elementos
que controlan donde divergen o convergen los flujos de secuencia en un proceso.
Utilizando flujos de secuencia se producen: la ramificación, bifurcación, combinación y
unión de flujos en un proceso.
A continuación, en la figura 2.30, se describen las compuertas básicas:
Elemento Descripción Notación
Exclusivo Se utiliza cuando en un
punto del flujo se escoge un
camino de varios
disponibles, basado en los
datos del proceso. Como
convergencia es utilizada
para confluir caminos
excluyentes.
Evento Se utiliza cuando en un
punto del flujo se escoge un
camino de varios
disponibles. La selección del
camino se basa en eventos,
los caminos restantes se
deshabilitan.
Paralelo Se utiliza cuando varias
actividades pueden
realizarse concurrentemente
o en paralelo. Como
convergencia el flujo
continuará cuando todos los
caminos activos hayan
confluido.
Figura 2.30 Compuertas
Objeto de Datos (Data Object)
Los objetos de datos deben estar contenidos en procesos o subprocesos. Una misma
instancia de un objeto de datos puede aparecer varias veces en un proceso. Esto sirve para
34
simplificar las conexiones de un diagrama. Representan los datos o información
consumidos o producidos por las actividades. El elemento DataStore fue incorporado en la
última versión de BPMN y es utilizado en este trabajo como uno de los elementos orígenes
para realizar transformaciones. En la figura 2.31, se describe el elemento DataStore.
Elemento Descripción Notación
Depósito de Datos
(DataStore)
Proporciona un mecanismo
para que las actividades
recuperen o actualicen
información almacenada que
persistirá más allá del
alcance del proceso.
Mediante un Data Store
Reference el DataStore
puede ser visualizado en
distintos lugares de un
proceso.
El Data Store Reference se
puede utilizar como origen o
destino de una asociación de
datos.
Figura 2.31 Depósito de datos
Conectores de Objetos (Connecting Objects)
Definen la manera de vincular elementos como objetos de flujo y artefactos. En la figura
2.32, se pueden observar los conectores de objetos.
Elemento Descripción Notación
Flujo de Secuencia Define el orden en que las
actividades se ejecutarán en
un proceso. El origen y el
destino del flujo de
secuencia deben ser uno de
los siguientes objetos de
flujo: Eventos, Actividades
y Gateways
No puede cruzar los límites
de un pool.
Flujo de Mensajes Sirve para mostrar el flujo
de mensajes entre dos
35
participantes que están
preparados para enviar y
recibir mensajes. Dos Pools
separados en un diagrama de
colaboración pueden
representar a los dos
participantes.
Asociaciones Se utiliza para asociar
artefactos con objetos de
flujo.
Asociaciones de Datos Se utilizan para mover datos
entre los objetos de datos y
las entradas y salidas de las
actividades, procesos y
GlobalTasks.
Figura 2.32 Conectores de objetos
Canales (Swimlanes)
Permiten la agrupación de elementos de modelado. Estos elementos son muy relevantes
porque son tomados para la realización de transformaciones. En la figura 2.33, se muestran
los elementos canales de BPMN 2.
Elemento Descripción Notación
Pools Un Pool es la representación
gráfica de un participante en
una colaboración.
Un Participante puede ser
una entidad específica (por
ejemplo, una empresa) o
puede ser una entidad
general (por ejemplo, un
comprador, vendedor o
fabricante).
No es necesario que un Pool
haga referencia a un
proceso. Es decir, puede ser
una caja sin elementos en el
interior.
36
Lanes Se utilizan para organizar y
categorizar actividades. Es
una subdivisión de un
proceso o de un Pool y
representa los diferentes
participantes en el interior
de una organización.
Figura 2.33 Canales
Artefactos (Artifacts)
Los artefactos brindan información adicional que no está relacionada con el flujo. Los
artefactos se pueden observar en la figura 2.34.
Elemento Descripción Notación
Grupo Agrupación de actividades
para propósitos de
documentación o análisis
Anotaciones Usada para proveer
información adicional a un
diagrama.
Figura 2.34 Artefactos
2.4.5 Diagrama de Colaboración
Es necesario el concepto de diagrama de colaboración para poder comprender el proceso de
creación de diagramas técnicos ejecutables. Un diagrama colaboración puede contener dos
o más Pools, que representan a los participantes en una colaboración. El intercambio de
mensajes entre los participantes se muestra mediante un flujo de mensajes que conecta a
dos Pools (o los objetos dentro de los Pools). Un Pool puede estar vacío o puede tener un
proceso dentro. Un Pool es la representación gráfica de un participante en una colaboración
[1]. Un Participante puede ser una entidad específica (por ejemplo, una empresa) o puede
ser rol general (por ejemplo, un comprador, vendedor o fabricante). Un Pool puede no estar
vinculado a un proceso. En la figura 2.35 se muestra un ejemplo de un diagrama de
colaboración genérico.
37
Figura 2.35 Ejemplo de Diagrama Ejecutable BPMN 2
2.4.6 Modelado de Diagramas BPMN 2.0 Ejecutables
El objetivo de esta sección es explicar cómo se puede diseñar un modelo técnico ejecutable
con el estándar BPMN 2.0 que pueda servir como origen de las transformaciones
propuestas en este trabajo. Además se presenta un ejemplo que integra los conceptos vistos
sobre el estándar de modelados de procesos.
BPMN 2.0 incorpora características nuevas para la construcción de modelos ejecutables.
Permite la construcción de diagramas que puedan ser ejecutados sobre un motor de
procesos.
Incorpora un metamodelo MOF que define la sintaxis abstracta y semántica de los
constructores del modelado. El metamodelo habilita el intercambio,
interoperatividad y ejecución de modelos.
Refina y formaliza la semántica de ejecución de BPMN
En base un diagrama del nivel operacional planteado en el BPM-Framework se pueden
agregar los detalles necesarios para obtener un modelo técnico que sea factible de ser
ejecutado en un BPMS. Este modelo tiene los detalles necesarios para poder realizar
transformaciones que permitan obtener componentes de software. Esto permite acercarse al
objetivo de alinear los modelos del negocio con modelos técnicos ejecutables y estos con el
desarrollo de software que permite automatizar los procesos de la organización.
Un modelo BPMN 2 ejecutable debe tener los atributos necesarios como para poder
convertirse en código XML (eXtensible Markup Language) sujeto a ser ejecutado por una
motor de procesos o transformado a entidades que puedan ser desplegadas en una
plataforma específica. Las características fundamentales que debe un modelo BPMN 2 para
que sea ejecutable son:
Debe tener el suficiente nivel de detalle. Es decir debe ser expresado con elementos
de BPMN 2 que no pueden ser expandidos a mayor nivel de profundidad como
Tarea de Servicio o Tarea de Script. Debe tener en cuenta los aspectos técnicos
necesarios para ser automatizado
38
El modelo debe estar sintácticamente y semánticamente correcto de acuerdo a la
especificación de la notación BPMN 2.
La herramienta de diseño con la que se crea el modelo debe ser compatible con la
semántica de ejecución de BPMN 2 de acuerdo a los requisitos de la especificación
con respecto a los procesos de ejecución [19].
Se tienen que incorporar detalles de ejecución como atributos del modelo. A partir
de esto se puede obtener un archivo de intercambio XML factible de ser exportado e
importado a una plataforma de implementación.
Hay que tener en cuenta aspectos como la especificación de interfaces de invocación
de servicio. La interfaz de lenguaje de definición de servicio utilizado debe ser
WSDL (Web Services Description Language). Considerar casos de excepción y
errores técnicos.
Una forma de construir un modelo BPMN 2 ejecutable puede ser:
Tomar el modelo del nivel operativo y convertirlo a un modelo técnico. La
consistencia entre los dos modelos debe permanecer. El modelo técnico debe
incorporar las funcionalidades o requerimientos que debe cumplir el software desde
el punto de vista de cada participante.
Se crea un diagrama de colaboración que muestra la interacción entre distintos
Pools. Cada Pool representa un participante que está subdividido en Lanes que
reflejan con precisión diferentes ámbitos de responsabilidad. La incorporación de
estos diferentes ámbitos ayuda a asegurar que el procesamiento de las actividades
está suficientemente descompuesto de tal manera que las operaciones de ejecución
están inequívocamente realizadas por un recurso específico y único.
A nivel técnico lo más importante es la creación de un nuevo participante que es un
Pool que representa al Sistema Informático que va a interactuar con los usuarios y
compartir mensajes. Dentro de este Pool se crean Lanes que muestran las tareas de
usuario por cada participante del proceso. Se agrega un lane que contiene los pasos
automáticos: Invocación de servicio por medio de tareas de servicios, programas
internos (scripts), etc..
Para poder implementar los procesos en una plataforma tecnológica es necesario
vincular las actividades del diagrama BPMN con el entorno de implementación.
En la figura 2.36, se detalla un diagrama ejecutable BPMN 2. Éste muestra una versión
simplificada de un proceso de generación de órdenes de compra en forma automática. El
diagrama contiene las características necesarias a nivel técnico para su ejecución en una
plataforma BPMS y/o en una plataforma como Java EE.
39
Figura 2.36 Ejemplo de Diagrama Ejecutable BPMN 2
El proceso comienza con un Evento de inicio condicional que se activa cuando una
condición de negocio se cumple y da inicio al proceso. En este caso se activa cuando el
nivel de inventario alcanza un punto de pedido.
Luego se crea la orden de compra que es almacenada en una base de datos a través de una
llamada a un procedimiento remoto o un servicio web. Esto se representa en el diagrama
con una Tarea de Servicio (Service Task) con nombre “Crear Orden de Compra”.
El jefe administrativo aprueba todas las órdenes de compra, la tarea de aprobar la orden es
una “Tarea de Usuario” donde se representa que el usuario revisa a través de una pantalla
del sistema, la orden de compra generada. Con una compuerta exclusiva se define si se
aprueba o no la orden. En el caso de que no se apruebe termina el proceso.
Si el resultado es aprobada, se utiliza una “Tarea de Servicio” para crear un PDF de la
orden de compra. Este elemento BPMN 2.0 tiene un evento adjunto que es un evento de
captura de error. Si durante la ejecución de la tarea automática se presenta algún error
(caída del servicio, error de conexión etc.), se dispara el evento de error y se activa la tarea
siguiente a éste. En este caso, dicha tarea se habilita para la generación manual del PDF de
la orden de compra por parte del Departamento de Compras.
Una vez generado el PDF de la orden de compra, ésta es enviada con la “Tarea de Script”
denominada “Enviar Orden de compra al Proveedor”. Este tipo de tarea permite el ingreso
de un script en un lenguaje que el motor de procesos de negocio pueda ejecutar. En este
caso, el script está relacionado al envío de la orden de compra a través de un correo
electrónico al proveedor. Finalmente se avisa a los participantes del proceso que la orden ha
sido enviada al proveedor con la tarea de envío “Notificar Orden de Compra Terminada”.
2.4.7 Intercambio de Modelos
El metamodelo BPMN 2 define todas las entidades con sus atributos y relaciones. Las
entidades pueden ser elementos visibles como tareas o Pools o invisibles como las
40
operaciones de un servicio web o su estructura de datos. BPMN 2 introduce un metamodelo
basado en MOF que define la sintaxis y semántica abstracta de los constructores de
modelado. El metamodelo permite el intercambio, interoperabilidad y ejecución de
modelos.
La especificación del estándar BPMN 2 define el formato de serialización XML y la
semántica de ejecución. Existen dos tipos de esquemas, el de intercambio de modelos y el
de semántica de ejecución.
El esquema de intercambio de modelos permite exportar e importar modelos de una
herramienta a otra sin utilizar formatos de serialización propietarios. BPMN 2 define dos
formatos de archivos que aseguran la interoperabilidad entre herramientas y motores de
procesos de distintos fabricantes. Se pueden definir los archivos BPMN mediante el
esquema XSD (XML Schema Definition) y con XMI (Extensible Model Interchange). Con
XSLT 8 eXtensible Stylesheet Language Transformations) se puede transformar entre
XSD y XMI.
El esquema de ejecución de la semántica permite definir en forma clara y precisa los
detalles técnicos del proceso. La semántica de ejecución BPMN 2 incluye:
Semántica de instanciación y terminación de procesos.
Semántica de diferentes tipos de actividades.
Semántica de diferentes tipos de compuertas
Semántica de diferentes tipos de eventos
La semántica de elementos no operacionales: Tarea Manual, tarea abstracta
2.5 Componentes del negocio Java EE
Teniendo en cuenta el objetivo de transformar un diagrama UML con estereotipos del perfil
Enterpise JavaBeans 3.1 (EJB 3) [6] con Java Persistence API 2 (JPA 2) [7] a código fuente
Enterprise Edition (Java EE) [22]. Es necesario describir los componentes de la capa del
negocio (plataforma Java EE) que son el producto final obtenido por las transformaciones
sucesivas de la presente propuesta de tesis.
2.5.1 Introducción
Los componentes del negocio Java EE están formados por los enterprise bean y el API de
persistencia JPA. EJB 3 es un estándar definido por Java Community Process
implementado por distintos fabricantes, es un componente del lado del servidor que
representa la capa del negocio dentro de una arquitectura de Capas de una aplicación
Enterprise, dentro de la tecnología Java EE.
41
EJB 3 brinda ventajas para el desarrollo de aplicaciones distribuidas y Enterprise,
consistentes en el desarrollo rápido y simple para aplicaciones: transaccionales, seguras y
portables. Una aplicación Enterprise java consta de una capa web, la capa del negocio y la
capa de datos. Los EJB son gestionados y desplegados en servidores de aplicaciones Java
EE [23], brindando a las aplicaciones servicios a nivel sistema como: seguridad, balanceo
de carga y clustering.
Según el tutorial Java EE 6 [8], un enterprise bean es un componente del lado del servidor
que encapsula la lógica del negocio de una aplicación. La lógica del negocio es el código
que cumple con los propósitos de la aplicación. En una aplicación de control de inventario,
los Enterprise beans podrían implementar la lógica del negocio en métodos como controlar
el nivel de inventario u ordenar un producto.
Los EJB contienen la lógica del negocio que opera sobre los datos de la empresa. Las
instancias de un enterprise bean son administradas en tiempo de ejecución por un
contenedor como por ejemplo GlassFish Server [24] o Jboss Server [25]. Los servicios
como transacciones y seguridad, pueden ser especificados junto con la lógica del negocio
de la clase enterprise bean en forma de anotaciones, o en un descriptor de despliegue XML.
El acceso del cliente es gestionado por el contenedor en el cual el enterprise bean es
desplegado. Este acceso es transparente para el cliente. El contenedor asegura que los beans
y sus clientes pueden ser desplegados en múltiples ambientes de ejecución sin re-
compilación.
La lógica del negocio reside en los enterprise beans y no en el lado del cliente, permitiendo
que el desarrollo del lado del cliente esté desacoplado de la lógica del negocio. Los
enterprise bean son componentes portables, reutilizables y pueden ser desplegados en
servidores que usen los estándares del API JEE. Pueden residir en diferentes servidores y
pueden ser invocados por un cliente remoto. El estándar EJB 3 es desarrollado por Java
Community Process (JCP).
JPA es un framework basado en Plain Old Java Object (POJO), que permite el mapeo
objeto/relacional en aplicaciones java EE. JPA es ampliamente utilizada en conjunto con
EJB a través de herramientas como hibernate y toplink. JPA es una especificación que
forma parte de Java EE y está definida por el Java Community Process.
2.5.2 Enterprise Java Beans
Existen dos tipos de Enterprise beans: Session y Message-driven. Los Session bean son
componentes reutilizables ideales para implementar la lógica de procesos de negocio.
Pueden tener interfaces locales, remotas, web services o ninguna. Deben ser empaquetados
en un ensamblado apropiado (jar, war o ear). Es responsabilidad del contenedor, manejar el
ciclo de vida del componente
Un cliente como una aplicación web JSP, un servlet o una aplicación standalone java
interactúan con un session bean a través de la invocación de sus métodos, esta invocación
se llama sesión. Un componente session bean es un POJO anotado, es decir, un pojo más
anotaciones es igual a un EJB. Un POJO es una clase java simple que no depende de un
42
framework específico. Una anotación es información añadida al código para comentar
mejor el código o para modificar la forma de compilar/ejecutar una clase concreta.
Un session bean está compuesto por una o más interfaces y una clase de implementación.
En la figura 2.37, se muestra en general los componentes que interactúan en un contenedor
Java EE y su relación con una aplicación cliente. EJB 3.1 introduce el concepto de vista sin
interfaz, que consiste en una variación de la vista Local, la cual expone todos los métodos
públicos de un Bean.
Figura 2.37 Ejemplo de contenedor Ejb3
Un cliente puede acceder a un session bean solamente a través de métodos definidos en la
interfaz del bean. La interfaz define la vista al cliente de un bean. Un session bean puede
ser invocado a través de Java Remote Method Invocation (RMI) por una interfaz Remota o
Local. El RMI es una forma utilizada por java para invocar métodos remotos.
El session bean realiza el trabajo por el cliente ocultando la complejidad del lado del
servidor. Hay tres subtipos de Sesion Bean, en el anterior estándar EJB 3 sólo existían el
Stateless y el Stateful, en EJB 3.1 se introducen los singleton session beans.
2.5.2.1 Stateless Session Beans
Un Stateless Session Beans mantiene un estado conversacional con el cliente. Cuando un
cliente invoca los métodos de un stateless bean, las variables de instancia del bean pueden
contener un estado específico del cliente, pero sólo por la duración de la invocación.
Cuando el método finaliza, el estado del cliente específico no se mantiene. Las instancias
pueden ser compartidas por los clientes. El contenedor tiene un pool de instancias, cuando
el cliente invoca un método se asigna una instancia, cuando la libera es retornada al pool.
En la figura 2.38, se muestra el ciclo de vida de un stateless session beans. Este tiene dos
estados para la invocación de métodos del negocio: no existe y listo.
43
Figura 2.38 Ciclo de vida de un stateless sesión beans
El contenedor EJB normalmente crea y mantiene un pool de stateless session beans,
comenzando el ciclo de vida de cada uno. El contenedor ejecuta la inyección de
dependencia y entonces invoca al método anotado @ PostConstruct si existe. El bean ahora
está listo para que sus métodos de negocio sean invocados por un cliente. Al final del ciclo
de vida, el contenedor EJB llama al método anotado @ PreDestroy, si es que existe. La
instancia del bean está listo para ser recolectado por el garbage collection.
Un bean de sesión sin estado es una clase java normal con anotaciones. En la figura 2.39, se
muestra un ejemplo de stateless sesión beans que implementa una interface remota con
nombre: ArticuloService. La anotación @Stateless identifica a un pojo como un
componente EJB stateless. Mediante @PersistenceContext se pueden inyectar referencias a
un EntityManager que proporciona lo necesario para manejar la persistencia. Como se
explica en la sección 2.5.4 el método persist del objeto manager permite almacenar una
instancia de la clase Articulo en la base de datos. En el método listaArticulo se muestran
dos líneas que permiten la consulta en la base de datos de los objetos de tipo Artículo.
Figura 2.39 Stateless Session Beans con Interface Remote
44
En la figura 2.40, se representa una interface remota que expone a los clientes los métodos
implementados por el stateless session beans de la figura anterior. La anotación @Remote
caracteriza a una interfaz java como interfaz remota de un componente EJB.
Figura 2.40 Interface Remote del Stateless Session Beans
2.5.2.2 Stateful Session Beans
El estado de un objeto consiste en los valores de sus variables de instancia. En un stateful
session beans, las variables de instancia representan el estado de una única sesión entre el
cliente y el bean de sesión. Debido a que el cliente interactúa con el bean a través de la
sesión, este estado se llama a menudo el estado de conversación. El estado se mantiene
durante la sesión del cliente con el bean. La instancia es reservada para el cliente y cada una
almacena la información del cliente. La sesión finaliza si el cliente remueve el bean o
finaliza su sesión.
Como se muestra en la figura 2.41, el cliente inicia el ciclo de vida mediante la obtención
de una referencia a un stateful session beans. El contenedor ejecuta una inyección de
dependencia y, a continuación, invoca el método anotado con @ PostConstruct, si existe. El
bean ya está listo para que sus métodos de negocio sean invocados por el cliente.
Figura 2.41 Ciclo de vida de un stateful sesión beans
En el estado listo el contenedor EJB puede decidir desactivar o colocar en modo pasivo el
bean moviéndolo a la memoria de almacenamiento secundario. En ese caso el contenedor
EJB llama al método anotado @PrePassivate antes de pasarlo al estado pasivo. Si un cliente
45
llama a un método de negocio en el bean mientras está en la etapa pasiva, el contenedor
EJB activa el bean, llama al método anotado @PostActivate y luego pasa al estado de listo.
Al final del ciclo de vida, el cliente invoca un método anotado @Remove, y el contenedor
EJB llama al método anotado @PreDestroy, si existe. La instancia del bean está listo para
para ser recolectado por el garbage collection.
El modelo de programación es similar para los tres tipos sesión beans. La diferencia entre
los mismos es la anotación sobre la declaración de la clase. En la figura 2.42, se muestra la
anotación que identifica a un stateful sesión beans.
Figura 2.42 Anotación de un stateful sesión beans
2.5.2.3 Singleton Session Beans
Un singleton sesión bean es instanciado una vez por aplicación y existe por el ciclo de vida
de la aplicación. Se utiliza cuando una simple instancia de un Enterprise bean es
compartida a través de accesos concurrentes de los clientes. Ofrece funcionalidades
similares a un stateless sesión beans pero difiere de este en que existe un solo singleton
sesión bean por aplicación. Mantiene el estado entre invocaciones de clientes pero no
mantiene el estado a través del apagado o fallo de servidores.
Las aplicaciones que usan un singleton session bean pueden especificar que el singleton
debe instanciarse al iniciar la aplicación, lo cual permite al singleton ejecutar tareas de
inicialización. El singleton puede ejecutar tareas de limpieza al cierre de la aplicación
porque opera a través del ciclo de vida de la aplicación.
En la figura 2.43, se muestra el ciclo de vida de un singleton sesión beans. El contenedor
EJB inicia el ciclo de vida mediante la creación de la instancia singleton. Esto ocurre sobre
el despliegue (deployment) de la aplicación si el singleton se anota @Startup. El
contenedor ejecuta cualquier inyección de dependencia y luego invoca al método anotado
@ PostConstruct si existe. El Singleton session beans ya está listo para que sus métodos de
negocio sean invocados por el cliente. Al final del ciclo de vida, el contenedor EJB llama al
método anotado @PreDestroy si existe. El singleton session bean ya está listo para ser
recolectado por el garbage Collection.
46
Figura 2.43 Ciclo de vida de un singleton sesión beans
En la figura 2.44, se observa la anotación @Singleton que marca a una clase java como
singleton sesión beans. Mientras que la anotación @Startup indica al contenedor EJB que
debe inicializar una instancia del singleton sesión beans al iniciar la aplicación, antes de
que el contenedor EJB acepte las solicitudes de los clientes.
Figura 2.44 Anotación que identifica a un singleton sesión beans
2.5.2.4 Message-Driven Bean
Un Message-Driven Bean (MDB) [8] es un componente enterprise bean que actúa como
oyente (listener) permitiendo a las aplicaciones Java EE procesar mensajes
asincrónicamente. Un MDB está a la espera de recibir mensajes en un canal de mensajes.
Cuando recibe un mensaje lo procesa y realiza una acción.
Las características de un MDB son:
No mantienen estado
Son gestionados por el contenedor
Son clases puras que no implementan interfaces de negocio (esto es porque no son
invocados por un cliente)
A diferencia de los otros tipos de Bean nunca estarán directamente conectados con
un cliente.
Se invoca de forma asincrónica.
Son relativamente de corta duración.
Ellos no representan directamente los datos compartidos en la base de datos, pero
pueden acceder y actualizar estos datos.
Teniendo en cuenta las transformaciones entre los modelos UML y Java EE que se
desarrollan en esta tesis, se detallan los requerimientos de una clase Message-Driven Bean:
Debe ser anotada con la anotación @ MessageDriven
Debe ser definida como pública.
La clase no puede ser definida como abstracta o final.
47
Debe contener un constructor público sin argumentos.
No se debe definir el método finalize.
En la figura 2.45, se muestra el ciclo de vida de un MDB. Por cada instancia de un MDB el
contenedor EJB realiza una serie de acciones. Si el MDB utiliza inyección de dependencia,
entonces el contenedor inyecta los recursos necesarios y referencias antes de instanciar al
MDB. Luego el contenedor ejecuta un método dentro del MDB marcado con la anotación
@PostConstruct, si existe.
Un bean gestionado por mensajes nunca pasa al estado pasivo y sólo tiene dos estados: no
existe y listo para recibir mensajes. Al final del ciclo de vida, el contenedor llama al método
anotado @ PreDestroy, si existe. Finalmente, el MDB queda listo para ser recolectado por
el garbage Collection.
Figura 2.45 Ciclo de vida de un message-driven bean
Los mensajes pueden ser enviados por cualquier componente de Java EE (una aplicación
cliente, otro enterprise bean, o un componente web) o por una aplicación Java Message
Service (JMS) o sistema que no utiliza la tecnología Java EE. Message-driven beans puede
procesar mensajes JMS u otra clase de mensajes.
JMS puede ser usada para acceder a sistemas de mensajería. JMS suministra dos modelos
de mensajería:
Publicar y Suscribir
Punto a Punto
En el modelo publicar/suscribir, un cliente JMS de tipo productor publica a sus mensajes en
un canal virtual llamado topic. A su vez, uno o varios clientes JMS de tipo consumidor se
suscriben a dicho topic si desean recibir los mensajes que en él se publiquen. Si un
suscriptor decide desconectarse del topic y más tarde reconectarse, recibirá todos los
mensajes publicados durante su ausencia.
En el modelo p2p, un cliente JMS de tipo productor publica sus mensajes en un canal
virtual llamado queue (cola). De manera similar al modelo publicar/suscribir, pueden existir
48
múltiples consumidores conectados al queue. Sin embargo, el queue no enviará
automáticamente los mensajes que le lleguen a todos los consumidores, sino que son estos
últimos los que deben solicitarlos al queue. De manera adicional, solo un consumidor
consumirá cada mensaje publicado: el primero en solicitarlo. Cuando esto ocurra, el
mensaje se borrará del queue, y el resto de consumidores no será siquiera consciente de la
anterior existencia del mensaje.
En la figura 2.46, se muestra un ejemplo de una clase Message-Driven Bean. A
continuación se explica las partes principales del código fuente:
Para indicar al contenedor EJB que es un componente Message-Driven Bean se
utiliza la anotación @MessageDriven.
Cuando la queue (cola) recibe un mensaje, el contenedor EJB invoca el método o
métodos oyentes de mensajes. Para un bean que utiliza JMS, el método onMessage
de la interfaz MessageListener es utilizado para el procesamiento de mensajes a
través de las instrucciones contenidas en él.
Figura 2.46 Ejemplo de clase MDB
2.5.3 Web Services
Web Services [8] es una tecnología que utiliza un conjunto de protocolos y estándares para
permitir la comunicación entre procesos y/o componentes independientes de la plataforma
y del lenguaje de programación utilizado. Son aplicaciones cliente-servidor que interactúan
mediante la utilización de la World Wide Web’s (WWW) y el protocolo HyperText
Transfer Protocol (HTTP) para el transporte de mensajes de los Web Services.
La interoperabilidad entre aplicaciones de software se logra mediante la utilización de
estándares como: Extensible Markup Language (XML), Simple Object Access Protocol
(SOAP), Web Services Description Language (WSDL) y Universal Description, Discovery
49
and Integration (UDDI). EJB permite crear Web Services a partir de stateless session beans
[26].
2.5.3.1 Relación de los Web Services con las Transformaciones
En la propuesta de la presente tesis los componentes Service Task del modelo técnico
BPMN 2 son transformados en operaciones de clases UML. Las operaciones de las clases
UML deben ser accedidas por clientes independientes de la plataforma elegida. Esto es
porque en el proceso del negocio pueden interactuar sistemas desarrollados con distintas
tecnologías. Para cumplir con este requerimiento las operaciones son expuestas como
puntos de servicio a través de web services. Esto permite incluir a la aplicación generada en
el marco de una arquitectura orientada a servicios (Service Oriented Architecture-SOA).
2.5.3.2 Tipos de Web Services
Java EE provee la funcionalidad para implementar web services de tipo “big” web services
y “RESTful” web services. Big web services utilizan el protocolo estándar Simple Object
Access Protocol (SOAP). Mediante XML se define la arquitectura y el formato de los
mensajes. La descripción de las operaciones que ofrece el servicio se describe con el Web
Services Description Language (WSDL). WSDL utiliza XML para describir los mensajes
SOAP y cómo estos mensajes son intercambiados.
Representational State Transfer (REST) es una forma liviana de implementar Web
Services; debido a que no se utilizan mensajes XML o definiciones WSDL del servicio.
REST define un set de principios arquitectónicos por los cuales se diseñan servicios web
haciendo foco en los recursos del sistema, incluyendo cómo se accede al estado de dichos
recursos y cómo se transfieren por HTTP hacia clientes escritos en diversos lenguajes.
En esta tesis utilizamos “Big” web services para ofrecer los servicios a las aplicaciones que
lo requieran.
2.5.3.3 Implementación de Stateless Session Bean con Web Services
Java API for XML-Web Services (JAX-WS) es una tecnología para la creación de servicios
web. JAX-WS utiliza tecnologías definidos por el World Wide Web Consortium (W3C):
HTTP, SOAP y WSDL. Permite a los desarrolladores escribir web services orientados a
mensajes y a llamadas a procedimiento remoto [8].
La API JAX-WS oculta complejidad de los mensajes SOAP al desarrollador. En el lado del
servidor se especifican las operaciones del servicio web mediante la definición de métodos
en una interfaz escrita en el lenguaje de programación Java. El desarrollador también
codifica una o más clases que implementan estos métodos.
El cliente crea un proxy (un objeto local que representa el servicio) y luego simplemente
invoca métodos en el proxy. Con JAX-WS, el desarrollador no genera o analiza mensajes
50
SOAP. Es el sistema en tiempo de ejecución JAX-WS que convierte las llamadas a la API y
atiende las respuestas hacia y desde los mensajes SOAP.
2.5.3.4 Ejemplo de Web Services con JAX-WS
Un web service JAX-WS es una clase Java marcada con la anotación @WebService. Esta
anotación declara a la clase como un punto final de acceso de un servicio web. La clase
debe declarar los métodos a los que un cliente puede acceder comunicándose con un web
services. Estos métodos del negocio deben ser anotados como @WebMethod; además
deben cumplir con el requerimiento de ser públicos y no estar declarados como static o
final.
En la figura 2.47, se muestra un ejemplo de implementación de un web service sobre un
stateless session bean. En el ejemplo, se observa a la declaración de la clase Hello marcada
como un web service usando la anotación @WebService. En el interior de la clase se
definen dos métodos. Un constructor público sin argumentos y el método mostrarHola. El
método mostrarHola se declara con la anotación @WebMethod; esto permite exponer al
método anotado a los clientes del web service para su acceso.
Figura 2.47 Ejemplo de clase stateless session bean anotada con @WebService
2.5.4 Java Persistent API (JPA)
Java Persistence API (JPA) proporciona un modelo de persistencia basado en POJO's que
permite el mapeo objeto/relacional en aplicaciones java [8]. JPA versión 2.1 es parte del
Java Specification Requests (JSR) 338, su uso no se limita a los componentes de software
EJB, también puede utilizarse en aplicaciones web y aplicaciones clientes; incluso fuera de
la plataforma Java EE, por ejemplo, en aplicaciones Java SE.
51
El mapeo objeto/relacional, es decir, la relación entre entidades Java y tablas de la base de
datos, se realiza mediante anotaciones en las propias clases de entidad, por lo que no se
requieren ficheros descriptores XML. También pueden definirse transacciones como
anotaciones JPA.
Una entidad representa una tabla en una base de datos relacional, y cada instancia de la
entidad corresponde a una fila de esa tabla. El artefacto de programación principal de una
entidad es la clase de entidad, si bien las entidades pueden utilizar clases auxiliares.
El estado de persistencia de una entidad se representa a través de campos persistentes o
propiedades persistentes. Estos campos o propiedades usan anotaciones para el mapeo de
estos objetos en el modelo de base de datos.
Los requerimientos que deben cumplir las clases Entity son:
Debe ser marcada con la anotación @Entity.
Tener un constructor público o protegido sin argumentos
No debe ser declarada final.
Implementar la interface Serializabe si es accedida remotamente.
Las variables de instancia persistentes pueden ser declaradas privadas o protegidas y
pueden ser accedidas solo por los métodos accesores set y get.
2.5.4.1 Relación de JPA con las Transformaciones
En la primera transformación se toman elementos BPMN 2 candidatos a ser entidades de
una aplicación como: Lane y DataStore. Estos se transforman a clases UML 2 y luego
pueden ser marcadas por el usuario con un perfil JPA 2 como entidades. JPA se utiliza en la
transformación final del modelo dependiente de la plataforma UML 2 con perfiles a código
Java EE. Se transforman las clases anotadas con el perfil Entity a entidades JPA.
2.5.4.2 Ejemplo
En la figura 2.48, se muestra un ejemplo de una clase entidad JPA. La clase Articulo se
marca con la anotación @Entity y el atributo id se marca con la anotación @Id. Utilizando
estás anotaciones la clase artículo se mapea a una tabla de la base de datos llamada Artículo
y cada una de sus propiedades será mapeada a una columna con el mismo nombre. Es
obligatorio que cada entidad tenga un atributo marcado como @id para permitir identificar
en forma única cada instancia de una entidad. Comúnmente se utiliza un atributo de tipo
Integer para ser anotado con @Id. La anotación @GeneretedValue da la posibilidad de que
la base de datos relacionada con la entidad genere en forma única e incremental el valor del
atributo identificador.
52
Figura 2.48 Ejemplo de clase Entity
2.5.4.3 Relaciones entre entidades
Se pueden establecer cuatro tipo de relaciones entre entidades:
Uno a uno: @OneToOne
Uno a muchos: @OneToMany
Muchos a uno: @ManyToOne
Muchos a muchos: @ManyToMany
Estas asociaciones pueden ser unidireccionales y bidireccionales. Las asociaciones
unidireccionales reflejan un objeto que tiene una relación con otro objeto. Por el contrario,
las asociaciones bidireccionales reflejan dos objetos que mantienen referencias al objeto
contrario. El concepto de cardinalidad se utiliza para determinar cuantos objetos pueden
haber en cada extremo de la asociación.
Asociación Uno a Uno
En este caso cada instancia de la entidad está relacionada con una sola instancia de la otra
entidad. Por ejemplo, en la figura 2.49, la clase Cliente tiene definido el atributo dirección
que referencia a la clase Dirección. La relación unidireccional uno a uno entre la entidad
53
fuente representada por la clase Cliente y la destino por la clase Dirección se hace a partir
de marcar el atributo dirección de la clase fuente con la anotación @OneToOne. Esto
genera las tablas Cliente y Dirección con sus atributos persistentes en la base de datos. En
la tabla Cliente se crea una columna con una clave foránea relacionada con el identificador
único de la tabla dirección.
Figura 2.49 Ejemplo de relación uno a uno
Asociación Uno a Muchos
Una instancia de una entidad puede estar relacionada con múltiples instancias de otra
entidad. Por ejemplo, en la figura 2.50, la entidad Cliente puede tener una relación uno a
muchos con la entidad Dirección. Esto se define marcando el atributo colección fuente de la
relación con la anotación @OneToMany. En la Clase cliente el atributo colección utilizado
es dirección.
Figura 2.50 Ejemplo de relación uno a muchos
Asociación Muchos a Uno
Múltiples instancias de una entidad pueden estar relacionadas con una sola instancia de otra
entidad. En el ejemplo de la figura 2.51, la asociación entre Empleado y Departamento es
desde la perspectiva del Empleado de muchos a uno. Se utiliza la anotación @ManyToOne
sobre la propiedad departamento de la clase empleado.
54
Figura 2.51 Ejemplo de relación muchos a uno
Asociación Muchos a Muchos
Sucede cuando una instancia de una entidad se relaciona con varias instancias de otra
entidad y viceversa. Como se observa en el ejemplo de la figura 2.52 cada empleado de una
empresa puede tener relacionados muchos proyectos y cada proyecto puede tener muchos
empleados que los integran. En este caso se utiliza la anotación @ManyToMany sobre cada
atributo persistente de tipo colección de cada entidad.
Figura 2.52 Ejemplo de relación muchos a muchos
2.5.4.4 Gestor de entidades
El trabajo de persistencia es realizado por un Gestor de Entidades representado por una
clase llamada EntityManager. Las instancias de esta clase son las que hacen el trabajo de
buscar, crear, modificar, eliminar o realizar consultas sobre las entidades.
Cada instancia de EntityManager se relaciona con un contexto de persistencia. El conjunto
de instancias de entidades administradas dentro de un gestor de entidades en un momento
dado se llama contexto de persistencia. Sólo una instancia de Java con la misma identidad
persistente puede existir en un contexto de persistencia.
La interface del EntityManager define los métodos que se utilizan para interactuar con el
contexto de persistencia. En el caso de que el EntityManager sea gestionado por el
contenedor del servidor de aplicaciones, el contexto de persistencia de cada instancia del
gestor de entidades es propagado a todos los componentes que lo utilizan dentro de un a
Java Transaction API (JTA) [8].
La Java Transaction API (JTA) se refiere al API de transacciones de java. Una transacción
representa un contexto de ejecución dentro del cual podemos realizar varias operaciones
como si fuera una sola. De forma tal que todas las operaciones son realizadas
satisfactoriamente, o el proceso se revierte en su totalidad.
Para obtener una instancia de un EntityManager, ésta se inyecta en los componentes de la
aplicación. En la figura 2.53, se muestra un ejemplo de inyección del EntityManager en una
clase stateless sesión bean.
55
Figura 2.53 Ejemplo de inyección de dependencia del EntityManager
Ciclo de vida de las instancias de una entidad
Las instancias de una entidad pueden estar en cuatro estados:
Nuevo: La nueva entidad no tiene identidad persistente y no se ha asociado a un
contexto de persistencia.
Manejado: La instancia de una entidad tiene identidad persistente y ha sido asociado
a un contexto de persistencia.
Separado: La instancia de una entidad tiene identidad persistente y actualmente no
está asociado a un contexto de persistencia.
Eliminado: La instancia de la entidad tiene una identidad persistente, está asociado a
un contexto de persistencia y está previsto su eliminación de la base de datos.
Operaciones con Entidades
Encontrar una Entidad
Para encontrar entidades utilizando el EntityManager se utiliza el método find. En la figura
2.54 se observa un ejemplo.
Figura 2.54 Ejemplo de método find sobre una entidad
Persistencia de una entidad
La persistencia de una entidad es la operación de tomar una entidad transitoria, o que no
tiene ninguna representación persistente en la base de datos, y almacenar su estado de
56
manera que pueda ser recuperado posteriormente. En la figura 2.55, se crea un nuevo
artículo y luego se persiste en la base de datos utilizando el método persist.
Figura 2.55 Ejemplo de persistencia de una entidad
Eliminar una entidad
Para eliminar una entidad esta debe estar presente en el contexto de persistencia. Esto
significa que la aplicación se ha encargado de obtener la instancia de la entidad mediante,
por ejemplo, un método find para que ésta sea una entidad manejada y se pueda eliminar.
En la figura 2.56, primero se encuentra un artículo y luego se elimina mediante el método
remove.
Figura 2.56 Ejemplo de eliminación de una entidad
2.5.4.5 Unidad de persistencia
La unidad de persistencia se refiere al conjunto de clases de tipo Entity que son
administradas por las instancias del EntityManager. Este conjunto de clases de entidad
representa los datos contenidos en una base de datos. Las unidades de persistencia se
definen por el archivo de configuración persistence.xml. En la figura 2.57, se muestra un
ejemplo del archivo persistence.xml. En la etiqueta persistence-unit se define el nombre de
la unidad de persistencia. En jta-data-source se describe la fuente de datos con la que se
vincula la unidad de persistencia.
57
Figura 2.57 Ejemplo de archivo persistence.xml
El archivo persistence.xml debe estar ubicado en el directorio META-INF. La unidad de
persistencia se puede empaquetar como parte de un archivo EJB de tipo Enterprise Archive
(EAR) o Java ARchive (JAR). También puede estar en un archivo JAR que contenga un
archivo EAR o Web Application Archive (WAR).
58
3. Estado del Arte
Introducción
En este capítulo, se presenta 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, posibilidades de
integración con tecnología y sistemas de gestión de procesos del negocio.
En la actualidad las empresas necesitan cambiar rápidamente para poder adaptarse a los
nuevos modelos de negocios lo cual significa la creación de procesos o la modificación de
los existentes. La mayoría de estos cambios están relacionados con la automatización de los
procesos del negocio. Estás necesidades han aumentado estos últimos años con la
globalización e Internet.
La automatización de procesos tiene relación directa con el desarrollo de software. Pero las
necesidades de incorporación rápida de procesos en las organizaciones no son cubiertas por
las arquitecturas y metodologías tradicionales de desarrollo. En la actualidad las
organizaciones necesitan implementar rápidamente sus procesos para poder ser competitivo
y cumplir con los objetivos estratégicos de la organización.
Es necesario utilizar alternativas que permitan acortar los ciclos de desarrollo de sistemas
integrando procesos del negocio y tecnologías de forma rápida y eficiente. Una alternativa
es la utilización de un enfoque orientado a procesos con la aplicación de MDA para lograr
mayores niveles de alineamiento entre los modelos de procesos del negocio construido por
los analistas del negocio y los componentes de software desarrollados por los profesionales
de la informática.
En este estado del arte se desarrollan aquellos métodos, técnicas, estándares que se
consideran interesantes analizar teniendo en cuenta los objetivos de la tesis. Las fuentes de
información utilizadas para el análisis se han seleccionado teniendo en cuenta los siguientes
aspectos:
Utilización del framework MDA y sus estándares relacionados.
Transformación de un modelo de proceso del negocio estándar a un modelo UML.
Transformación utilizando estándares de procesos del negocio a diagramas UML2 o
a una plataforma específica.
Transformación de UML 2 a una plataforma tecnológica
59
Para analizar la relación entre transformaciones MDA desde modelos de procesos del
negocio se recopilaron artículos considerando algunas bases de datos de artículos
importantes como: ACM, IEEE y Springer.
El capítulo se organiza de la siguiente forma: en el punto 3.1 se hace una descripción y
análisis de los principales: frameworks, estándares, enfoques y tecnologías relacionadas con
la propuesta de tesis, en 3.2 se describen y evalúan los trabajos relacionados siguiendo
cuatro criterios de análisis y en 3.3 se presentan las conclusiones.
3.1 MDA y Procesos del Negocio
3.1.1 Arquitectura Dirigida por Modelos
La Arquitectura Dirigida por Modelos (MDA) es un framework para el desarrollo de
software guiado por modelos y definido por el Object Management Group (OMG) [4]. Los
objetivos fundamentales de MDA son mejorar la: portabilidad, la interoperabilidad, la
productividad y la reutilización a través de la separación arquitectónica de conceptos [3].
MDA se apoya en diversos estándares para cumplir con el propósito de lograr la
interoperabilidad de las herramientas y plataformas. Lo antes expresado, posibilita evitar
problemas relacionados con la diversidad de plataformas y evolución tecnológica. Los
principales estándares en los que se basa MDA son: UML [5], QVT [4], MOF [4], OCL
[17] y XMI [21].
MDA especifica tres modelos con distintos niveles de abstracción: un modelo
independiente de la computación (CIM), el modelo independiente de la plataforma (PIM) y
un modelo específico de la plataforma (PSM). Un PSM se transforman automáticamente a
partir de un PIM y lo mismo ocurre con la generación de código a partir de un PSM. La
construcción y transformación de modelos es esencial en MDA. En [14] se define una
transformación como la generación automática de un modelo destino desde un modelo
origen.
Si bien MDA no especifica que lenguaje bien definido se puede utilizar en los niveles PIM
y PSM, se utiliza comúnmente UML. No es el caso de los modelos CIM que representan
los requerimientos del sistema, donde no hay consenso entre los autores sobre que lenguaje
de modelado utilizar. Incluso en algunos trabajos no consideran al nivel CIM en la
propuesta MDA. El estándar dice que debe haber trazabilidad entre el modelo CIM y el
PIM pero no describe cómo deben ser las transformaciones entre los modelos [3].
3.1.2 Modelado de Procesos del Negocio y BPMN
La captura de requerimientos es una actividad de la ingeniería de requisitos que constituye
la primera etapa en el desarrollo de un sistema de información. Los modelos de procesos de
negocio se utilizan como una forma de documentar y formalizar los requerimientos del
60
negocio. Si bien estos modelos pueden no ser suficientes para analizar y entender el entorno
de una organización. En el nivel CIM es factible utilizar lenguajes de modelos de procesos
del negocio bien definidos.
Existen varias notaciones para el modelado de procesos del negocio entre las más usadas
destacan: Event-driven Process Chain (EPC) [30], Diagramas de actividad UML 2 [29] y
BPMN [19]. EPC fue creado en año 1992 en el Instituto de Sistemas de información en
Saarbruecken, Alemania. Como se explica en [30] EPC ha sido superado por BPMN por ser
un estándar, su mayor expresividad y el soporte cada vez mayor de las herramientas.
El diagrama de actividad forma parte de los diagramas que componen al estándar UML. Es
otro diagrama que se utiliza desde su creación en el año 1997 para crear modelos de
procesos. El diagrama de actividad se puede utilizar para especificar flujos de procesos que
van a ser embebidos en un sistema de información. Pero para modelar procesos del negocio
que van a ser ejecutados en un Sistema de Gestión de Procesos el Negocio (BPMS) el
principal estándar es BPMN 2 porque su notación es superior a los diagramas relacionados
con UML y su objetivo principal es el modelado de procesos del negocio [20].
Varios trabajos relacionados con transformaciones de CIM a PIM como [32], [33] y [34]
proponen usar como modelo origen al diagrama de actividad UML, aun cuando estos
modelos no son bien conocidos por los expertos del negocio. El objetivo fundamental de
BPMN es proveer una notación que sea entendida tanto por la gente relacionada con el
negocio como por la gente responsable del desarrollo e implementación de los procesos del
negocio. Esto permite reducir la brecha entre los procesos del negocio y su implementación
en una plataforma tecnológica. Otro aspecto importante es que el estándar para el modelado
de procesos del negocio permita su ejecución en un motor de proceso del negocio.
A partir de la versión BPMN 2.0 del estándar cuenta con la notación y semántica de
ejecución que da la posibilidad de su despliegue directamente en un motor de procesos del
negocio. En la versión anterior de BPMN no existía esta posibilidad lo cual hacía necesario
su transformación a un lenguaje de ejecución de procesos como el estándar Web Services
Business Process Execution Language (WS-BPEL). Trabajos como [35] presentan
propuestas de transformación de BPMN a BPEL.
En año 2004 la versión 1 de BPMN había sido normalizada por la Iniciativa para la Gestión
de Procesos de Negocio (Business Process Management Initiative-BPMI). Se utiliza
ampliamente como notación para el modelado del negocio. En el caso de los
desarrolladores de sistemas lo utilizan con propósito de documentación o análisis del
negocio. WS-BPEL se estandarizó en el año 2007 y es reemplazado actualmente por
BPMN 2 por incluir un metamodelo que permite su ejecución directamente sin necesidad
de un lenguaje de ejecución.
3.1.3 BPM y BPMS
Lograr la consistencia entre los procesos del negocio y los sistemas informáticos es uno de
los objetivos de la Gestión de Procesos de Negocio (Business Process Management, BPM)
[36]. BPM es una disciplina de gestión por procesos de negocio apoyada fuertemente por
61
tecnologías de información. Esto está generando una gran oferta de herramientas llamadas
BPMS (Business Proceses Management Suites) que son capaces de implementar y
automatizar los procesos de negocio para hacerlos más controlables, transparentes y ágiles.
Para esto se utiliza el estándar BPMN 2 ejecutado sobre BPMS en conjunto con la
Arquitectura Orientada a Servicios (Service Oriented Architecture, SOA) [37].
Un modelo técnico de BPMN 2.0 puede ejecutarse o ser implementado por una Suite de
gestión de procesos del negocio (Business Process Managment Suite, BPMS). Un BPMS
tiene componentes como: motor de workflow, panel de control, interfaz de usuario, APIs de
integración y en ocasiones Enterprise Service Bus (ESB) [20]. Entre los principales
sistemas de gestión de procesos del negocio Open Source que implementan un motor de
procesos para la ejecución de BPMN 2 están: Activiti [38], JBPM [39] y BonitaSoft [40].
Las plataformas Activiti y JBPM tienen funcionalidades similares en cuanto a
características implementadas sobre el estándar BPMN 2. BonitaSoft se diferencia de las
anteriores por el enfoque de implementación de procesos que plantea. Con Activiti y JBPM
es necesario trabajar con código fuente para implementar un proceso, en su lugar con
BonitaSoft se modelan los procesos, configuran e implementan sin escribir código fuente.
La ventaja de Activiti es la flexibilidad que brinda al permitir que el desarrollador tenga el
control de proceso y pueda integrarlo sin problemas en una aplicación que ya está en
producción.
3.2 Trabajos Relacionados
El análisis de los trabajos relacionados con la tesis se centra en las transformaciones que
cubran total o parcialmente los niveles definidos por MDA. En especial los trabajos que
transforman desde un modelo CIM y llegan a código fuente. Teniendo en cuenta que pocas
propuestas implementan en su totalidad el enfoque MDA. Dividimos en partes el análisis y
comparación de los trabajos estudiados.
3.2.1 Criterios de Análisis de las propuestas
El análisis de las propuestas se centra en los siguientes aspectos:
Transformaciones MDA
Para cada una de las propuestas de transformaciones, se estudiará si se adaptan a las
características de MDA, analizado además en qué nivel; es decir, si definen modelos
para los distintos niveles de abstracción propuestos por MDA y si se especifican
transformaciones entre ellos.
Uso de Estándares
En este punto se analizarán los siguientes puntos:
Las propuestas utilizan lenguajes de modelado estándares como BPMN o UML.
62
Las transformaciones son formalizadas utilizando lenguajes estándares como
QVT.
Los metamodelos utilizados se basan en lenguajes estándares y tienen las
características y son lo suficientemente completos para permitir el modelado en
herramientas Open Source
Alineamiento entre el Negocio y los Sistemas Informáticos
Se resaltará las diferencias entre las transformaciones propuestas haciendo hincapié
en el mapeo entre modelos CIM y PIM. Luego las transformaciones a modelos PIM
a PSM y de PSM a componentes de software. Esto es lo que nos va a permitir
verificar el alineamiento entre el modelo del negocio y los sistemas informáticos de
la organización.
Integración con BPMS
Se analiza si las soluciones propuestas contemplan una arquitectura que permite su
integración con un BPMS. Para que los trabajos cumplan con esta característica tienen que
utilizar lenguajes de modelado compatibles con los motores de procesos de negocios.
3.2.2 Transformaciones de Procesos del Negocio a UML y SoaML
Consideramos para este análisis aquellos trabajos que utilizan la arquitectura MDA para la
transformación de procesos del negocio a modelos de clases UML. Teniendo en cuenta que
a la fecha existen pocos artículos de investigación que parten de un modelo BPMN 2.0 para
definir transformaciones, se toman artículos que tienen como origen estándares actuales
utilizados para el modelado de procesos del negocio a nivel CIM. Estos son comúnmente
diagramas BPMN versión 1 y diagramas de actividad UML.
En los trabajos de investigación analizados se detectan las siguientes categorías de
transformaciones que tienen como origen modelos de procesos del negocio:
Transformación de BPMN y diagrama de actividad a UML
Transformación de BPMN a diagramas SOA
Relación entre BPMN 2.0 y datos(Diagrama de Clases-Modelo ER)
a. Transformación de BPMN y diagrama de actividad a UML
En este punto se analizan los trabajos que tienen en cuenta como modelo origen a un
modelo de procesos del negocio y como destino un diagrama UML, se describen a
continuación los trabajos más representativos:
a.1. Obtaining Analysis-Level Class and Use Case Diagrams from Business Process
Models (Rodríguez, A., Fernández-Medina, E. y Piattini, 2008)
63
En [31] se proponen un conjunto de transformaciones desde un diagrama de procesos
descriptivo basado en BPMN 1.0 a un diagrama de actividad UML y desde el diagrama de
actividad a casos de uso y clases UML de análisis. Las transformaciones se formalizan con
el lenguaje estándar QVT y se utiliza una versión simplificada de los metamodelos de
BPMN versión 1, diagramas de actividad y de clases UML.
Esta propuesta se basa en MDA sólo para la transformación de un CIM a un PIM. No tiene
en cuenta las transformaciones para llegar al código fuente. El proceso del negocio es sólo
modelado a nivel descriptivo e implementado dentro de la aplicación utilizando el proceso
unificado, dejando de lado la posibilidad de la utilización de un BPMS para la
automatización de los procesos.
a.2. Transformation of a Process Business Model to Domain Model
(Ernesto Suarez, Medardo Delgado, Elizabeth Vidal, 2008)
Por su parte en [32] se presenta un método para la transformación de Diagramas de
Actividad a un diagrama de clases UML. Este trabajo se diferencia de otros porque aporta
una forma para asociar las clases teniendo en cuenta el vínculo entre objetos que entran y
salen de un elemento Action de un diagrama de actividad. Luego agrega refinamientos para
llegar a un diagrama de clases con relaciones más detalladas.
Como las propuestas anteriores sólo contemplan las transformaciones de CIM a PIM. En
esta propuesta no se formalizan las transformaciones mediante un lenguaje estándar y
tampoco se definen metamodelos. Se diferencia de [31] en que obtiene relaciones entre
clases a partir del diagrama de actividad. Contempla la alineación del proceso del negocio
con la utilización del proceso unificado, sin considerar transformaciones automáticas o
semiautomáticas para llegar a los componentes de software. Esto dificulta la trazabilidad
entre los elementos del negocio y los componentes de un sistema informático.
a.3. Transformation From CIM to PIM Using Patterns and Archetypes
(Kherraf S, Lefebvre E, Suryn W, 2008)
En la propuesta presentada en [41] las transformaciones tienen como origen a un diagrama
de actividad UML 2 para modelar los procesos del negocio y un diagrama de casos de uso.
Como destino genera un modelo PIM definido por un diagrama de componentes y un
diagrama de clases UML. Para definir las reglas de transformación se utilizan 4 arquetipos
propuestos por [42].
En el caso de esta propuesta no define los metamodelos basados en estándares y por lo
tanto no formaliza las reglas que permitan la automatización de las transformaciones del
modelo CIM a PIM. El modelo de procesos del negocio es representado por un diagrama de
actividad lo que dificulta la integración de la propuesta con un BPMS.
b. Transformación de BPMN a diagramas SOA
Otros autores realizan aportes en transformaciones desde modelos de procesos del negocio
obteniendo como destino alguna representación de modelos de servicios como SoaML [43].
64
SoaML es un estándar para identificar, especificar e implementar servicios en una
arquitectura orientada a servicios (SOA) [44]. En los artículos más recientes toman como
origen de las transformaciones a un modelo BPMN versión 1 o 2. Representativo de este
tipo de trabajos son [33] [45], en estos se plantean transformaciones de CIM a PIM
formalizadas mediante QVT y ATL respectivamente.
b.1. From BPMN business process models to SoaML service models: a transformation
driven approach
(Delgado A, Garcia-Rodriguez de Guzman I, Ruiz F, Piattini, M.,2010)
Esta propuesta [33] plantea como objetivo transformar un modelo BPMN a un modelo de
servicios definido mediante el estándar SoaML utilizando lenguajes y metamodelos
estándares. Plantea mapeos como la transformación entre un elemento Pool de BPMN
versión 1 y un elemento Participante de SoaML.
Como los trabajos analizados anteriormente la propuesta no se beneficia de las
características del estándar BPMN 2. Por esta razón no se integra a motores de procesos
BPMS. Tampoco se valida la propuesta realizando las transformaciones del modelo SoaML
a una tecnología concreta como REST o Web Services. Sólo permite vincular un proceso
del negocio a puntos de servicios que luego se deben implementar con una tecnología para
poder conectarse a las aplicaciones ya existentes.
b.2. Aligning business and IT models in service-oriented architectures using BPMN
and SoaML
(Brian Elvesæter , Dima Panfilenko , Sven Jacobi , Christian Hahn, 2010)
En el caso del trabajo planteado en [45] se definen reglas de transformación para el mapeo
entre modelos BPMN 2 a SoaML. Presenta mapeos adicionales a los presentados en [33]
como la transformación entre el elemento Task de BPMN 2 y el elemento Action de
SoaML.
Se diferencia del trabajo anterior porque utiliza la versión 2.0 del estándar BPMN con las
ventajas que este ofrece. Como la propuesta anterior tiene como objetivo la generación
automática de servicios a partir de procesos del negocio. No considera las transformaciones
necesarias para lograr los componentes de software que expongan los servicios generados.
c. Transformaciones entre BPMN 2.0 y datos (Diagrama de Clases, Diagrama de
entidad relación)
En relación a esta tesis de maestría es necesario el análisis de propuestas relacionadas con
las transformaciones de BPMN a modelos relacionados con la persistencia de datos. Entre
los trabajos destacados se encuentra a [46] y [47].
c.1. A. Sturm, “Enabling off-line business process analysis: A transformation based
approach,” in BPMDS, 2008
En [46] se presentan reglas para la transformación entre un diagrama BPMN versión 1 y un
esquema de datos de tipo copo de nieve que representa la estructura de un data warehouse.
65
El esquema de datos es utilizado por un motor multidimensional de tipo relacional para
realizar análisis sobre los datos. Este trabajo presenta una propuesta para alinear los
procesos del negocio con el aspecto de análisis de los datos. No se presentan metamodelos
ni tampoco se formalizan las transformaciones.
c.2. Cruz E, Machado R, Santos M. “From Business Process Modeling to Data Model:
A systematic approach”, Quality of Information and Communications Technology
(QUATIC), Pp: 205 – 210. 2012
En [47] se propone la transformación de elementos BPMN 2 relacionados con datos como
los participantes de un proceso a entidades de un modelo de datos. La relación entre las
entidades se deduce a partir del intercambio de información entre los participantes y las
actividades que manipulan los almacenes de datos. Se identifican parcialmente las
relaciones entre las entidades de datos y se obtienen sólo los atributos mínimos que se
logran obtener en base a los elementos de BPMN. Como la propuesta anterior no se definen
las transformaciones utilizando un lenguaje estándar.
3.2.3 Análisis de Transformaciones de Procesos del Negocio a UML y
SoaML
En los trabajos [31], [32], [33] proponen lograr el alineamiento entre procesos del negocio
y los sistemas informáticos mediante transformaciones entre los modelos de procesos del
negocio y modelos de análisis UML. Luego toman los modelos PIM resultado de las
transformaciones y lo utilizan como modelos de análisis de metodologías de desarrollo de
software. Con utilización de estos métodos la trazabilidad con los componentes del negocio
pierde gradualmente el vínculo al no tener en cuenta las transformaciones MDA para llegar
a los componentes de software.
En todas las propuestas analizadas no se tiene en cuenta en la arquitectura del sistema la
posibilidad de automatizar el modelo de proceso del negocio en un BPMS. Implementar
una suite BPM brinda la posibilidad de desacoplar el aspecto de la gestión del proceso del
negocio del desarrollo del sistema. Esta restricción en algunas propuestas es por motivo de
no utilizar un lenguaje de modelado estándar que pueda ser ejecutado en motores de
procesos del negocio.
Con respecto a las transformaciones propuestas por cada una de los trabajos analizados, se
pueden describir los aportes del método propuesto en esta Tesis de Maestría. Por un lado, la
definición de transformaciones desde un modelo CIM a componentes del negocio
expresados en un lenguaje de programación. La utilización de lenguajes de modelado
estándares y metamodelos completos que permiten la integración de nuestra solución con
BPMS y herramientas de modelado. Estas características influyen en aumentar el grado de
alineamiento de los procesos del negocio con los sistemas informáticos. En las propuestas
donde se utiliza BPMN 2.0 no contemplan la utilización de un modelo de procesos
ejecutable en un BPMS.
66
En la tabla 3.1, se muestra un resumen de las principales características analizadas en los
trabajos relacionados. La tabla incluye en la última columna a nuestra propuesta para
destacar las diferencias con el estado del arte actual.
Tabla 3.1 Resumen de las principales propuestas para las transformaciones de CIM a PIM Propuestas Analizadas Nuestra
Propuest
a a.1 a.2 a.3 b.1 b.2 c.1 c.2
Transformaciones MDA Parcial Parcial Parcial Parcial Parcial Parcial Parcial Total
Uso de Estándares
2.1 Lenguaje de modelado
estándares
SI SI SI SI SI SI SI SI
2.2 Transformaciones
formalizadas
SI SI NO SI SI NO NO SI
2.3 Metamodelos estándares Parcial Parcial NO SI SI NO NO SI
3 Alineamiento entre el
Negocio y los Sistemas
Informáticos
Parcial Parcial Parcial Parcial Parcial Parcial Parcial Parcial
4 Integración con BPMS NO NO NO NO NO NO NO SI
3.2.4 Transformaciones de PIM a PSM y de PSM a código
Los modelos PIM no contienen detalles de la plataforma concreta en que la solución va a
ser implementada. Estos modelos surgen como resultado del análisis y diseño. La mayoría
de las transformaciones que presentan los autores utilizan un modelo PIM representado por
el lenguaje UML, considerado el estándar de facto a nivel académico e industrial.
En este punto se presenta un análisis de las propuestas de transformación recientes y
representativas, las cuales se describirán resaltando sus principales características, así como
sus aportaciones y limitaciones a la hora de ser utilizadas en un proceso de desarrollo
basado en MDA en el contexto de un desarrollo basado en procesos de negocios. Como
criterios que servirán para la evaluación y comparación de las propuestas utilizamos los
puntos 1 y 2 definidos en la sección 1.3.2.1:
Applying the MDA approach for the automatic generation of an MVC2 web
application
(Daissaoui A, Casablanca, Morocco, 2010)
En [48] se transforma de un diagrama de clases a una aplicación web con una arquitectura
MVC (Model/View/Control) que implementa funciones: Create, Read, Update and Delete
(CRUD). Las funciones CRUD son las operaciones que permiten: crear, consultar,
actualizar y borrar registros en una base de datos u objetos en la capa de persistencia. Como
fuente utiliza un metamodelo simplificado de UML. Como metamodelos destino utiliza una
versión simplificada de base de datos, la lógica del negocio representada principalmente
por componentes bean, la capa de interfaz del usuario representada especialmente por
páginas JSP y por último el metamodelo del componente controlador. La transformación se
formaliza mediante un algoritmo.
67
A Hybrid Model Transformation Approach Based On J2EE Platform
(Kun Ma,Bo Yang, 2010)
En [49] se presentan reglas de transformación entre PIM a PSM y de PSM a código Java 2
EE. El modelo PIM está representado por un diagrama de clases UML con estereotipos que
marcan a las clases que son entidad de datos. Se utiliza un diagrama de actividad para
especificar operaciones CRUD que van a ser expuestas como servicios web. Las entidades
que representan a los datos son transformados en un modelo de tablas con operaciones
CRUD sobre la capa de negocios de la aplicación. Usa un motor de templates llamado
FreeMarker que se utiliza para la transformación del modelo PSM a código java.
Model-Driven transformation with approach by modeling: From UML to N-tiers Web
Model
(Esbai R, Erramdani M,Mbarki S, Arrassen I, 2011)
En [50] se transforma de un diagrama de clases UML a una aplicación Web de N-Capas.
Utiliza QVT como lenguaje de transformación. Propone un metamodelo origen que es una
versión simplificada de UML. Luego define tres metamodelos destino: metamodelo destino
que representa al patrón Data Access Object (DAO), un metamodelo que representa la
lógica del negocio y un metamodelo que representa a los conceptos de MVC2 (Model-
View-Controller) vinculados a la interfaz del usuario.
3.2.5 Análisis de Transformaciones de PIM a PSM y de PSM a código
Los modelos PSM derivados de los PIM, contienen los detalles de la plataforma o
tecnología con que se implementará la solución. Estos modelos también son representados
por UML y se emplean mecanismos como el uso de perfiles UML para identificar a los
elementos del modelo origen. Esto permite saber qué reglas y qué tipo de mapeo se aplicará
en la transformación. Un modelo PIM con estereotipos de un perfil UML es un modelo
PSM que contiene los detalles de la plataforma de implementación [14].
En general los trabajos relacionados con esta propuesta de tesis presentan distintos
enfoques para la generación de código basado en UML. Enfoques simples usan sólo
diagramas de clases, generando un único esqueleto de código. Otros utilizan una
combinación de diferentes diagramas (por ejemplo, diagramas de clases con el de estado,
diagrama de secuencia y / o actividades) para generar código.
Los artículos analizados en la sección anterior [48], [49] y [50] en general transforman un
diagrama de clases UML a un modelo PSM que utiliza patrones de diseño como MVC y
DAO. Estás propuestas no contemplan la trazabilidad con respecto a un modelo CIM
estándar definido, por ejemplo, por analistas del negocio. Nuestra propuesta se diferencia
de estas en usar componentes basados en estándares en cada parte de la transformación del
modelo CIM al código fuente. Al trabajar con estándares nuestra propuesta se puede
integrar fácilmente con motores de procesos del negocio que utilicen BPMN 2.
68
3.3 Conclusiones
En este capítulo se ha presentado una revisión del estado de la investigación relacionada
con el tema de las transformaciones MDA que parten de un modelo CIM representado por
un modelo de proceso de negocio estándar.
En primer lugar, y dado que esta Tesis de Maestría propone una aproximación basada en
MDA y modelos de procesos del negocio para el desarrollo orientado a procesos, se ha
presentado un resumen y análisis de los estándares, frameworks y tecnologías relacionadas
describiendo sus principales características.
Se han revisado también las principales propuestas de transformaciones desde modelos
CIM representado por modelos de procesos del negocio a modelos PIM representados por
modelos de análisis UML y el estándar, poniendo especial énfasis en el análisis de aspectos
como: adaptación de las propuestas a los modelos MDA, uso de metamodelos estándares,
formalización de las transformaciones, alineamiento de modelos de procesos con
componentes de software y el nivel de utilización BPMS en la arquitectura delas
soluciones. Se ha realizado, además, un estudio comparativo de tales propuestas, donde se
han destacado las principales aportes del método que se propone en esta Tesis de Maestría.
Por otro lado, se han analizado otras propuestas que, aunque no se han ocupado de
transformaciones desde modelos CIM, sí han realizado aportes en las transformaciones
desde modelos PIM a PSM y de PSM a código fuente. En este caso se han estudiado los
trabajos más representativos y actuales propuestos.
En general, tras la revisión del estado actual de la investigación relacionada con la
problemática de las transformaciones de CIM a componentes de software, se puede obtener
una conclusión principal, y es que en la actualidad no existen propuestas que definan
transformaciones desde modelos de procesos del negocio BPMN 2 alineadas mediantes
transformaciones MDA hasta llegar a componentes de software de la capa del negocio.
Además del agregado de que el modelo de procesos del negocio se ejecute en un BPMS.
En relación a lo anterior se puede observar que la mayoría de las propuestas no tiene en
cuenta la separación del aspecto de procesos del negocio de la aplicación, implementando
los modelos de procesos utilizando metodologías de desarrollo tradicionales como el
proceso unificado para alinear los procesos del negocio con la aplicación. De esta forma se
desaprovecha las ventajas de los sistemas de gestión de procesos del negocio para ejecutar
los procesos y desacoplar este aspecto de las aplicaciones.
Como conclusión final del capítulo, se puede destacar que el aporte principal del método
propuesto en esta Tesis de Maestría respecto de las actuales propuestas relacionadas con las
transformaciones de procesos de negocios a componentes de software, y es que es la única
propuesta que define un enfoque orientado a procesos para el desarrollo de la capa del
negocio y persistencia en un marco MDA, permitiendo alinear los modelos de procesos de
negocio con las tecnologías disponibles actualmente y los componentes del software de la
capa del negocio de una aplicación.
69
Nuestra propuesta define un enfoque para el desarrollo orientado a procesos que vincula un
modelo BPMN 2 con los componentes de la capa del negocio y persistencia de una
aplicación. La Tabla 3.2, presenta a modo de resumen, las características generales del
método que se presenta en esta Tesis de Maestría. En ella se integran los criterios utilizados
en la evaluación de las propuestas.
Tabla 3.2 Características de la Propuesta
Transformaciones MDA Se cubren niveles CIM, PIM, PSM y componentes del
negocio. Se definen las transformaciones MDA entre los
modelos.
Uso de Estándares
Lenguaje de modelado
estándares
Nivel CIM: Modelado de procesos del negocio: BPMN 2.0
Nivel PIM: UML 2
Nivel PSM: UML 2 con perfiles UML
Transformaciones
formalizadas
Se utiliza el estándar de la OMG. El lenguaje QVT-
Relations.
Metamodelos
estándares
Se utilizan metamodelos completos basados en estándares.
Alineamiento entre el
Negocio y los Sistemas
Informáticos
Se definen transformaciones desde el nivel CIM
Integración con BPMS Se emplea el lenguaje y metamodelo estándar BPMN 2.0
que nos permite utilizar un modelo de procesos ejecutable
en un sistema de gestión de procesos de negocio
70
4. Transformación de Modelos de
Procesos del Negocio BPMN 2.0 a
Componentes de la Capa del Negocio Java
EE
En este capítulo se presenta la transformación propuesta en esta Tesis de Maestría. Se
propone la transformación en forma automática y/o semiautomática de modelos de
procesos ejecutables definidos con el estándar BPMN 2 [1] a componentes Java EE [22].
En la figura 4.1, se muestra en general la transformación propuesta. Se parte de un
diagrama BPMN 2.0 ejecutable y a través de transformaciones se obtienen componentes
Java Enterprise. El modelo BPMN 2 ejecutable se transforma a un modelo UML 2
independiente de la plataforma. En base al modelo UML 2 [5] independiente de la
plataforma se genera un modelo UML 2 específico de la plataforma Java EE. Finalmente,
del modelo UML 2 específico de la plataforma se generan los componentes de código
fuente Java EE. Los modelos UML 2 intermedios generados permiten también la
transformación a otras tecnologías.
Figura 4.1 Resumen de la transformación propuesta
Como se explica en el capítulo de introducción, las transformaciones propuestas tienen
como objetivo:
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.0, y el software que automatiza a estos procesos.
Para cumplir los objetivos fue necesario definir 3 transformaciones en el marco de la
Arquitectura Dirigida por Modelos (MDA) [3].
De un modelo técnico BPMN 2 a un diagrama de clases UML (modelo
independiente de la plataforma).
71
Del diagrama UML obtenido en el punto anterior a un diagrama UML con
estereotipos del perfil EJB3.1 [6] -JPA2 [7] (Modelo dependiente de la plataforma).
Transformar el último modelo a código fuente java que compone los elementos de
la capa del negocio Java EE.
Como se representa en la figura 4.2 se parte de un modelo CIM BPMN 2.0 y a través de
transformaciones con el lenguaje QVT-Relations [4] y la herramienta Acceleo [9] se
obtienen componentes de una aplicación Java Enterprise.
Figura 4.2 Modelos MDA y el lenguaje utilizado para las transformaciones
4.1 Componentes de la Transformación
Las transformaciones de modelos utilizando el estándar QVT-Relations se realizaron en el
contexto de la arquitectura de metamodelos MOF (Meta Object Facility). La Figura 4.3,
muestra la transformación propuesta. El uso del estándar MOF y el concepto de
metamodelo es fundamental en MDA. MOF describe una arquitectura basada en cuatro
niveles de abstracción llamados M0, M1, M2 y M3.
72
Figura 4.3 Transformación propuesta en el marco de la arquitectura de la OMG que
sustenta MOF
Los metamodelos BPMN 2 y UML 2 se representan como instancias del metamodelo
MOF. El metamodelo UML 2-Profile Ejb 3.1-JPA 2 se refiere a que el metamodelo UML
se ha extendido con un perfil Ejb3.1-JPA 2 para disponer de conceptos propios de la
plataforma de implementación a utilizar.
La primera transformación (BPMN 2.0 a UML 2) es de un modelo independiente de la
computación (CIM) a un modelo independiente de la plataforma (PIM). Se define en el
nivel M2 teniendo como Metamodelo MOF fuente BPMN 2.0 y como Metamodelo MOF
destino UML 2.
La segunda transformación (UML 2 a UML 2-Profile Ejb 3.1-JPA 2) es de un modelo
independiente de la plataforma (PIM) a un modelo especifico de la plataforma (PSM). Se
define en el nivel M2 teniendo como Metamodelo MOF fuente UML 2 y como
Metamodelo MOF destino UML 2-Profile Ejb 3.1-JPA 2.
Para realizar las transformaciones se utiliza la herramienta Medini QVT [14]. Esta es una
herramienta integrada en el entorno de desarrollo Eclipse, que permite la ejecución de
transformaciones QVT expresadas con la sintaxis textual del lenguaje Relations.
Tomando como entrada el metamodelo Jee (Ejb 3.1-Jpa2) y la instancia de este modelo
generada a partir transformación explicada anteriormente, se aplica la herramienta Acceleo
para generar el código de la aplicación.
4.1.1 Relación de la Propuesta con Otros Componentes Vinculados a la
Arquitectura de una Aplicación SOA
Es prioridad en este trabajo de tesis, utilizar estándares como BPMN 2 y UML2, que
permitan que el producto de las transformaciones puedan utilizarse con herramientas o
73
plataformas que sean compatibles con esos estándares. Las transformaciones propuestas
parten de un diagrama BPMN 2.0 estándar que se puede ejecutar en un Sistema de Gestión
de Procesos del Negocio.
Los Sistema de Gestión de Procesos del Negocio, son plataformas de software que
contienen comúnmente: un editor de BPMN 2, un motor de procesos y herramientas de
soporte. Su característica principal es que permite desplegar un proceso ejecutable
recorriendo automáticamente el flujo de secuencia de la lógica modelada. Distingue entre
tareas que van a ser ejecutadas en forma manual por los usuarios y aquellas automáticas
que se delegan por ejemplo a servicios web. Por este motivo no tiene sentido desarrollar
estás funcionalidades en un sistema y se vuelve indispensable integrar los sistemas
informáticos con estás plataformas de gestión de BPMN 2.
Las reglas del negocio son algoritmos que se encapsulan en los programas. Los procesos
del negocio se integran a motores de reglas del negocio. Estos Sistemas de Gestión de
reglas del Negocio (Business Rules Management System-BRMS) dan la posibilidad de
desacoplar las reglas del negocio de la aplicación. Básicamente permiten la administración
y ejecución de reglas del negocio. BPMN 2 incorpora un tipo de actividad con nombre
“Regla de Negocio” que da la posibilidad de identificar en qué punto del flujo interviene
una reglas del negocio.
Los procesos del negocio ejecutables se modelan con elementos como Service Task que se
pueden comunicar con: aplicaciones o servicios web. Como se explica en [51], es una
buena práctica separar la lógica del proceso de la lógica de integración. Para lograr esto lo
ideal es incorporar a la arquitectura de la aplicación un ESB (Enterprise Service Bus) que
permita la separación entre la definición de los procesos del negocio y la lógica de
transformación por un lado y la lógica para comunicarse con las aplicaciones por otro lado.
La utilización de un ESB permite la implementación de una arquitectura orientada a
servicios (SOA) con interfaces estandarizadas.
Los componentes generados en las transformaciones propuestas en esta Tesis están
incluidos en una arquitectura formada por:
Sistema de Gestión de Procesos de Negocio (BPMS)
Sistema de Gestión de Reglas del Negocio (BRMS-Business Rules Management
Systems)
Bus de servicios de empresa (ESB-Enterprise Service Bus).
Componentes del negocio Java EE:
En la figura 4.4 se muestra un diagrama que muestra la relación de los componentes
utilizados o generados por la propuesta y un ESB. El producto final de las transformaciones
son componentes que se ejecutan en un contenedor Java EE.
74
Figura 4.4 Componentes de la Propuesta
4.1.2 Definición de las Transformaciones con QVT
La definición de las transformaciones es la parte central del presente trabajo de tesis. Los
metamodelos utilizados se explican en los anexos 1 y 2. En las secciones 4.2, 4.3, y 4.4 de
este capítulo se explican las propuestas de transformación desde un modelo BPMN 2 a
código fuente de componentes Java EE. Los conocimientos previos relacionados con las
secciones siguientes han sido desarrollados en los capítulos anteriores.
4.2 Transformación de BPMN 2 a UML 2
En esta sección, se explican las reglas de transformación propuestas de un modelo técnico
BPMN 2.0 a un modelo UML 2 con la aplicación de un perfil independiente de la
plataforma. En este caso se utiliza como metamodelo MOF fuente BPMN 2.0 y como
Metamodelo MOF destino UML 2. Los metamodelos fuente y destino se explican en los
anexos 2 y 3 respectivamente. En los destinos de las transformaciones se utilizan
anotaciones del perfil independiente de la plataforma. Los conceptos básicos para la
creación de perfiles se explica en la sección 2.3.6 y el perfil independiente de la plataforma
se explica en la sección 4.2.2..
Desde la sección 4.2.3 hasta la sección 4.2.11 se explican las transformaciones de un
modelo técnico BPMN 2.0 a un modelo UML 2. En el Anexo 3, se detalla el código fuente
QVT Relations de las transformaciones. Esta transformación es fundamental en la
propuesta de tesis porque genera a partir de un modelo de procesos un modelos UML 2
estándar con anotaciones independientes de la tecnología. A partir de este modelo UML 2
se puede generar código fuente en distintas tecnologías u otros modelos como se hace en la
segunda transformación. En la sección siguiente, se plantea un ejemplo que describe en
general la transformación propuesta.
75
4.2.1 Ejemplo Genérico de Transformación de BPMN 2 a UML 2
En este punto se presenta un ejemplo genérico en el cual se aplican las transformaciones
que se explican en las secciones siguientes. La figura 4.5, muestra el diagrama Bpmn 2 a
partir del cual se ha generado la instancia en formato XMI del metamodelo BPMN. Este se
observa en la figura 4.6, utilizando un visualizador de los objetos que componen el archivo
XMI.
Figura 4.5 Ejemplo genérico de diagrama BPMN 2
Figura 4.6 Ejemplo genérico de diagrama BPMN 2 con visualizador de formato xmi
76
En la figura 4.7, 4.8 y 4.9, se observa el resultado de aplicar la primera transformación. Se
obtiene el modelo de salida instancia del metamodelo UML2. Este modelo UML2 que se
obtiene como resultado es factible de modificar por cualquier herramienta que cumpla con
el estándar UML 2.
Figura 4.7 Resultado de la Transformación BPMN 2.0 a UML 2
Figura 4.8 Resultado de la Transformación BPMN 2.0 a UML 2. Paquete business. Vista
UML 2
77
Figura 4.9 Resultado de la Transformación BPMN 2.0 a UML 2. Paquete entities. Vista
UML 2
En base al modelo obtenido producto de la transformación de BPMN2 a UML2 el
desarrollador puede agregar, modificar o eliminar los elementos que considere necesario
del modelo UML2 para cumplir con los requerimientos de los usuarios. Puede agregar
estereotipos del perfil independiente de la plataforma, atributos, operaciones, clases y
asociaciones entre las clases.
En el diagrama de la figura 4.10 se puede observar que:
Se agrega el estereotipo Create y el parámetro lane1 a la operación ServiceTask1 de
la clase Lane1Service.
Se agrega el estereotipo Create a la operación ServiceTask2 de la clase
Lane2Service.
Figura 4.10 Diagrama de Clases UML 2 modificado por el desarrollador
78
4.2.2 Perfil Independiente de la Tecnología
Como parte de esta tesis se diseña un perfil independiente de la tecnología que permite
anotar distintos elementos del modelo y especialmente las operaciones de las clases UML
para permitir generar automáticamente el código fuente necesario. En la figura 4.11, se
muestra como la clase Lane1Service ha sido anotada como <<WebService>> para contener
entre sus operaciones métodos que se van a exponer a otras aplicaciones, por ejemplo,
usando REST. La operación serviceTask1 ha sido anotada como una operación web
(<<WebMethod>>) y como una operación que va realizar la creación(<<Create>>) de un
objeto lane1. Esto permite transformar en forma directa el modelo UML 2 obtenido desde
el modelo BPMN 2.0 a cualquier tecnología.
Figura 4.11 Perfil Independiente de la Tecnología Aplicado a una operación de una clase
Este perfil es transversal a los dos modelos UML2 producto de las transformaciones
propuestas. Es decir, las anotaciones se utilizan en el modelo UML 2 obtenido a partir de la
primer transformación (transformación de un modelo BPMN 2.0 a un modelo UML 2) y en
el modelo UML 2 obtenido a partir de la segunda transformación (transformación de un
modelo UML 2 a un modelo UML 2 con perfil JavaEE).
En la figura 4.12, se muestra el perfil independiente de la tecnología y en la tabla 4.1 se
explican sus componentes.
Figura 4.12 Perfil Independiente de la Tecnología
79
Tabla 4.1 Descripción de Elementos del Perfil Independiente de la Tecnología
Estereotipo Reglas de Transformación
Create Permite crear una instancia del objeto pasado como parámetro.
Update Permite actualizar una instancia del objeto pasado como
parámetro.
Deactivate Permite anular una instancia del objeto pasado como parámetro.
El atributo activo del objeto pasa de ce cero a uno.
Read Trae el objeto pasado como parámetro.
Search Busca el objeto en base a criterios de búsqueda.
VRead Trae una versión específica del objeto pasado como parámetro.
History Trae el historial del objeto pasado como parámetro.
WebMethod Permite marcar a una operación para que sea convertida en un
método que se expone en un Web Services.
WebService Permite anotar una clase como WebService.
Entity Permite anotar una clase como persistente. Es decir que las
instancias de esa clase se van almacenar en una base de datos.
4.2.3 Generación de modelo UML 2 con paquetes: entities y business
La transformación se explica en la tabla 4.2 y en las figuras 4.13 y 4.14. Se genera un
modelo UML 2 con dos paquetes con nombre: business y entities. En el paquete business,
se crean las clases que van a contener las operaciones relacionadas con la lógica del
negocio de la aplicación. En el paquete entities, se crean las clases que luego se van a
convertir en entidades persistentes.
Tabla 4.2 Generación de model UML2 y Paquetes business y entities. Vista textual.
Modelo Origen Reglas de Transformación Modelo Destino
Se genera un paquete UML 2 con
nombre business.
uml::Package
Se genera un paquete UML 2 con
nombre entities.
uml::Package
Origen Transformación Destino
Figura 4.13 Generación de model UML2 y Paquetes business y entities. Vista XMI.
80
Figura 4.14 Generación de model UML2 y Paquetes business y entities. Vista UML2.
La figura 4.15, muestra la declaración con nombre bpmn2uml2 que tiene como modelo
origen al modelo bpmn2 y destino al modelo uml. El modelo bpmn declara al metamodelo
Bpmn2 como metamodelo y el modelo uml declara como metamodelo a Uml2. La
transformación ModelBpmnToModelUml genera un modelo UML 2 en el destino. La
relaciones generaPackageBusiness y generaPackageEntities transforman a Definitions en
los paquetes business y entities.
Figura 4.15 Transformación de Definition BPMN 2.0 a Package UML2. Vista QVT
Relations.
A continuación de explican las transformaciones generadas en el paquete business.
81
4.2.4 Transformación de un elemento Process de BPMN 2.0 a un elemento
Class UML 2.0
En la tabla 4.3 y en la figura 4.16 se explica la transformación de un elemento Process a
una clase contenida en el paquete business. La clase se crea dentro del Package business si
se cumple la precondición de que no existen elementos Lane dentro del modelo origen. Las
clases creadas dentro del package business luego son transformadas en componentes
Session Bean del modelo específico de la plataforma. En la figura 4.17, se define el código
QVT de la relación.
Tabla 4.3 Regla de transformación de un Proceso BPMN 2.0 a una Clase UML 2.Vista
textual.
Modelo Origen Reglas de Transformación Modelo Destino
bpmn2::Process El elemento Process de BPMN
2 se transforma en un elemento
Class de UML 2 dentro del
Package business.
uml::PackageableElement::Class.
Anotada con <<WebService>>
Origen Transformación Destino
Figura 4.16 Transformación Process BPMN 2 a Class UML 2. Vista XMI.
82
Figura 4.17 Transformación Process BPMN 2 a Class UML 2. Vista QVT Relations.
4.2.5 Transformación de un elemento Lane de BPMN 2.0 a un elemento
Class UML 2.0
En el caso que en el modelo BPMN 2 origen existan elementos Lane dentro de un elemento
Process, estos son transformados en clases dentro del paquete business. En la tabla 4.4, se
explica la transformación con sus componentes. Como se puede observar en la figura 4.18,
el modelo BPMN 2 está formado por un proceso compuesto por un elemento LaneSet que a
su vez contiene elementos Lane. En el modelo destino se genera una clase UML2 por cada
elemento Lane de BPMN 2.
El motivo de esta transformación es obtener como destino las clases que van agrupar las
operaciones que van a encapsular la lógica del negocio de la aplicación. Está lógica va
acceder a las entidades persistentes y brindar una fachada de servicios para permitir su
acceso a los programas clientes.
83
Uno de los patrones de diseño utilizado para definir una clase dentro del paquete business
consiste en generar una clase por cada caso de uso. Las secuencias de tareas sin
interrupción contenidas en un elemento Lane las podemos considerar como equivalentes a
un caso de uso. En este caso utilizamos el concepto de Step, que consiste en definir un caso
de uso por cada secuencia de tareas sin interrupción de un actor [52]. Teniendo en cuenta
esto se genera una clase fachada de servicios por cada conjunto de tareas contenidas en un
elemento Lane. La clases generadas a partir del elemento Lane son marcadas con la
anotación <<WebService>>.
Tabla 4.4 Regla de transformación de un elemento Lane BPMN 2.0 a una Clase UML 2.
Vista textual.
Modelo Origen Reglas de Transformación Modelo Destino
bpmn2::Lane El elemento Lane de Bpmn 2
se transforma en un elemento
Class de UML dentro del
Package Business.
uml::PackageableElement::Cl
ass. Anotada con
<<WebService>>.
Origen Transformación Destino
Figura 4.18 Transformación de Lane BPMN 2 a Class UML2. Vista XMI.
En la figura 4.19, se presenta el código de la relación LaneToClass, donde se define la
precondición que solo permite crear una clase por cada Lane si el número de elementos
Lane en el modelo origen es mayor a cero. En la cláusula where se encuentra la llamada al
código que aplica la anotación a la clase UML 2 generada.
84
Figura 4.19 Transformación de Lane BPMN 2 a Class UML2. Vista QVT Relations.
4.2.6 Transformación de un elemento ServiceTask de BPMN 2.0 a un
elemento Operation de una Clase UML 2.0
En la tabla 4.5 y en las figuras 4.20 y 4.21, se explica la transformación de un elemento
ServiceTask de BPMN 2.0 a un elemento Operation de una Clase UML 2.0. Teniendo en
cuenta que un elemento ServiceTask de BPMN 2.0 se utiliza para representar un servicio
web. Entonces, se transforma este elemento en una operación UML 2 marcada como
método web con la anotación <<WebMethod>>.
Tabla 4.5 Transformación de ServiceTask BPMN 2 a Operation UML 2. Vista textual. Modelo Origen Reglas de Transformación Modelo Destino
bpmn2::ServiceTask El elemento ServiceTask de Bpmn 2
se transforma en un elemento
Operación dentro de un elemento
Class de UML, dentro del paquete
business.
uml::Operation. Anotada
con WebMethod.
85
Origen Transformación Destino
Figura 4.20 Transformación de ServiceTask BPMN 2 a Operation UML 2. Vista XMI.
Figura 4.21 Transformación de ServiceTask BPMN 2 a Operation UML 2. Vista UML 2.
En la figura 4.22, se puede observar el código de la relación ServiceToOperation.
Figura 4.22 Transformación de ServiceTask BPMN 2 a Operation UML 2. Vista QVT
Relations.
86
4.2.7 Transformación de un elemento DataStore de BPMN 2.0 a
elementos Operation de una Clase UML 2.0
En la tabla 4.6 y en las figuras 4.23 y 4.24, se explica la transformación de un elemento
DataStore de BPMN 2.0 a elementos Operation de una Clase UML 2.0. El motivo de esta
transformación es generar las operaciones necesarias para poder gestionar la clase
persistente que se crea luego en la sección 4.2.9 a partir del elemento DataStore.
Tabla 4.6 Transformación de DataStore BPMN 2 a Operaciones UML 2. Vista textual. Modelo Origen Reglas de Transformación Modelo Destino
bpmn2::DataStore El elemento DataStore de
Bpmn 2 de se transforma en
Operaciones UML 2 de una
clase dentro del paquete
entities.
uml::Operations. Con
anotaciones: create, update,
deactivate, search.
Origen Transformación Destino
Figura 4.23 Transformación de DataStore BPMN 2 a Operaciones UML 2. Vista XMI.
Figura 4.24 Transformación de DataStore BPMN 2 a Operaciones UML 2. Vista UML 2.
En la figura 4.25, se puede observar una parte del código de la relación que realiza la
transformación. Se puede ver como en la cláusula enforce genera la operación add
(agregar). Luego la operación add es marcada con la anotación Create. El resto del código
fuente la transformación se puede ver en el Anexo 3.
87
Figura 4.25 Transformación de DataStore BPMN 2 a Operaciones UML 2. Vista QVT
Relations.
A continuación de explican las transformaciones generadas en el paquete entities.
4.2.8 Transformación de un modelo BPMN 2.0 a Elementos Generales
UML2
En la tabla 4.7 y en las figuras 4.26 y 4.27, se explica la transformación de un elemento
Definitions de BPMN 2.0 a elementos clases y asociaciones de UML 2. El motivo de esta
transformación es generar clases generales cuyos elementos puedan ser heredados por las
clases del modelo generado. La clase EntityGeneral contiene atributos generales como
description(descripción), active (activo), company (empresa) y user (usuario). El campo
active determina si una instancia esta anulada o no. La clase company sirve para que el
modelo generado contemple la posibilidad de gestionar objetos de distintas empresas. La
clase user permite vincular a cada registro con un usuario. Las clase generadas son
marcadas con la anotación <<Entity>>.
88
Tabla 4.7 Transformación de un modelo BPMN 2.0 a Elementos Generales UML2. Vista
textual. Modelo Origen Reglas de Transformación Modelo Destino
bpmn2::Definitions El elemento Definitions de
Bpmn 2 se transforma en
clases y asociaciones UML 2
que son utilizadas por otros
elementos del modelo
generado.
uml::Class (EntityGeneral)
uml::Class (User)
uml::Class (Company)
uml:Associations
Anotadas con <<Entity>>
Origen Transformación Destino
Figura 4.26 Transformación de un modelo BPMN 2.0 a Elementos Generales UML2. Vista
XMI.
Figura 4.27 Diagrama UML2 destino. Elementos Generales UML2.
4.2.9 Transformación de un elemento DataStore a elementos UML 2
En la tabla 4.8 y en las figuras 4.28 y 4.29, se explica la transformación de un elemento
DataStore de BPMN 2.0 a elementos clases y asociaciones de UML 2. El modelo resultante
se utiliza en la transformación explicada en la sección 4.2.7. La transformación se
fundamenta en estimar que si tenemos en el modelo origen un artefacto que representa a
una entidad persistente, entonces, existen altas probabilidades que en el modelo destino se
tenga que modelar una clase compuesta por una colección de objetos. La clase que
representa a la colección de objetos se relaciona con una clase que es un tipo de algún
objeto.
89
Tabla 4.8 Transformación de un elemento DataStore BPMN 2 a elementos UML2. Vista
Textual. Modelo Origen Reglas de Transformación Modelo Destino
bpmn2::DataStore El elemento DataStore de
Bpmn 2 se transforma en
clases y asociaciones UML 2
dentro del Package entities.
Elementos Class y Associations.
Las entidades son anotadas con
<<Entity>>.
Origen Transformación Destino
Figura 4.28 Transformación de un elemento DataStore BPMN 2 a elementos UML2. Vista
XMI.
Figura 4.29 Transformación de un elemento DataStore BPMN 2 a elementos UML2. Vista
UML 2.
Como se explica en la sección 4.2.10, se genera un elemento clase de UML 2, por cada
elemento Lane de BPMN 2. Los elementos DataStore que están contenidos en el elemento
Lane son transformados en una clase compuesta por objetos como se explicó al inicio de la
sección. Se estima que va haber una asociación entre la clase generada para el elemento
Lane y la clase principal (DataStore1) generada a partir de cada elemento DataStore. Esta
asociación se puede observar en la figura 4.30.
Figura 4.30 Asociación de DataStore con Entidad Lane
90
En la figura 4.31, se puede observar una parte del código QVT Relations de la
transformación. El resto de la transformación se detalla en el Anexo 3.
Figura 4.31 Parte de la transformación de un elemento DataStore BPMN 2 a elementos
UML2. Vista QVT Relations.
4.2.10 Transformación de un elemento Lane de BPMN 2.0 a un elemento
Class UML 2.0
En el caso que en el modelo BPMN 2 origen existan elementos Lane dentro de un elemento
Process estos son transformados en Clases dentro del Package business. Como se muestra
en la figura 4.26, el modelo BPMN 2 está formado por un proceso compuesto por un
elemento LaneSet que a su vez contiene elementos Lane. En la tabla 4.9 y en las figuras
4.32 y 4.33, se explica la transformación de un elemento Lane de BPMN 2.0 a una clase
UML 2. La transformación se fundamenta en estimar que un elemento Lane de BPMN 2.0
puede ser en el modelo destino una clase persistente.
Tabla 4.9 Regla de transformación de un elemento Lane BPMN 2.0 a una Clase UML 2.
Vista textual.
Modelo Origen Reglas de Transformación Modelo Destino
91
bpmn2::Lane El elemento Lane de Bpmn 2
se transforma en un elemento
Class de UML dentro del
Package Business.
uml::PackageableElement::Cl
ass. La clase es anotada con
<<Entity>>.
Origen Transformación Destino
Figura 4.32 Transformación de Lane BPMN 2.0 a un elemento Class UML 2.0.Vista XMI.
Figura 4.33 Transformación de Lane BPMN 2.0 a un elemento Class UML 2.0.Vista UML
2.
En la figura 4.34, se puede observar el código QVT Relations de la relación LaneToClass.
Se puede ver en el código que se verifica si el proceso que contienen al elemento Lane es
ejecutable. También se puede observar que se define la precondición que sólo permite crear
una clase por cada Lane, si el número de elementos Lane en el modelo origen es mayor a
cero. En la relación LaneToClassEntity1 se aplica a la clase la anotación <<Entity>>.
92
Figura 4.34 Transformación de Lane BPMN 2.0 a un elemento Class UML 2.0.Vista QVT
Relations
4.2.11 Transformación de un elemento Participant de BPMN 2.0 a un
elemento Class UML 2.0
En la tabla 4.10 y en las figuras 4.35 y 4.36, se explica la transformación de un elemento
Participant de BPMN 2.0 a una clase UML 2. La transformación se fundamenta en estimar
que un elemento Participant de BPMN 2.0 puede ser en el modelo destino una clase
persistente.
Tabla 4.10 Regla de transformación de un elemento Participant BPMN 2.0 a una Clase
UML 2. Vista textual.
Modelo Origen Reglas de Transformación Modelo Destino
bpmn2::Participant El elemento Participant de
Bpmn 2 se transforma en un
elemento Class de UML
dentro del Package Entities.
uml::PackageableElement::Cl
ass
93
Origen Transformación Destino
Figura 4.35 Transformación de Participant BPMN 2 a elemento Class UML 2. Vista XMI.
Figura 4.36 Transformación de Participant BPMN 2 a elemento Class UML 2. Vista UML
2.
En la figura 4.37, se puede observar el código QVT Relations de la relación
ParticipantToClass
94
Figura 4.37 Transformación de Participant BPMN 2 a elemento Class UML 2. Vista QVT
Relations.
4.3 Transformación de un modelo UML2 con perfil
independiente de la tecnología a un modelo UML2 con perfil
Ejb3.1-JPA2
En esta sección, se explican las principales reglas de transformación propuestas de UML 2
con perfil independiente de la tecnología a UML 2 con perfil Ejb3.1-JPA2. En este caso se
utiliza como metamodelo MOF fuente UML2 y como Metamodelo MOF destino a UML 2
con la aplicación del perfil JavaEE-JPA2. El metamodelo fuente y destino se explica en el
anexo 2. El Perfil JavaEE-JPA2, es dependiente de la plataforma y se explica en la sección
4.3.2. En la sección 2.5, se desarrollan los temas de JavaEE y JPA2. Desde la sección 4.3.4
hasta la sección 4.3.5 se explican las transformaciones de un modelo UML 2 a un modelo
UML 2 con la aplicación de un perfil JavaEE-JPA2. En el Anexo 4, se detalla el código
fuente QVT Relations de las transformaciones. En la sección siguiente, se plantea un
ejemplo que describe en general la transformación propuesta.
95
4.3.1 Ejemplo de Transformación de UML2 con perfil independiente de la
tecnología a UML2 con perfil Ejb3.1-JPA2
Como se explicó en la sección 4.2; en base al modelo obtenido producto de la
transformación de BPMN2 a UML2 el desarrollador puede agregar, modificar o eliminar
los elementos que considere necesario al modelo UML2 para cumplir con los
requerimientos de los usuarios. Se pueden aplicar estereotipos del perfil independiente de la
tecnología sobre los elementos que considere necesario. Siguiendo el ejemplo planteado en
la sección 4.2.1, en las figuras 4.38 y 4.39, se puede observar el modelo UML 2 obtenido
con agregados y modificaciones del desarrollador. En la figura 4.38, vemos que en el
paquete business se ha modificado la operación serviceTask2 con el agregado de la
aplicación de la anotación <<Create>> y del parámetro lane2.
Figura 4.38 Diagrama de Clases UML 2 del Paquete business Modificado por el
Desarrollador
En la figura 4.39, se puede observar el paquete entities con los componentes modificados
por el desarrollador. Con fines didácticos suponemos que el desarrollador elimina los
siguientes elementos del modelo UML2 origen: Pool1, Pool2, Lane1, User y Company. Se
modifica la asociación entre DataStore1 y Lane2. Se agrega un atributo a las entidades:
DataStore1Item, Lane2 y a TypeDataStore1. Se agregan dos elementos Enumeration Literal
al elemento del tipo Enumeration con nombre StateDataStore1.
96
Figura 4.39 Diagrama de Clases UML 2 del Paquete entities modificado por el
Desarrollador
Las figuras 4.40 y 4.41 muestran el resultado de la segunda transformación de un diagrama
UML 2 a un diagrama UML 2 con perfiles Java EE. Se puede ver en la figura que
componentes como clases, atributos, operaciones y asociaciones tienen anotaciones
específicas de la plataforma Java EE. En las secciones 4.3.2 y 4.3.3 se describen los perfiles
UML 2 utilizados.
Podemos analizar las transformaciones realizadas por un lado para los elementos del
paquete Business y por otro para los elementos del paquete Entities.
En la figura 4.40, vemos que en el paquete Business a las clases originales se les ha
aplicado anotaciones Stateless y WebService. Por cada clase se ha generado una interface
para el acceso local y remoto de los métodos implementados en los Stateless Sesión Beans.
Por este motivo las interfaces tienen aplicadas las anotaciones <<Local,Remote>>.
También las operaciones de las clases que estaban anotadas con la anotación WebMethod
del perfil independiente de la tecnología, se les aplicó la anotación WebMethod del perfil
JavaEE. Esta transformación permite el acceso de los métodos vía WebServices.
Las clases generadas en el paquete Business heredan de la clase AbstractEntityService. La
clase AbstractEntityService está compuesta por métodos genéricos que tienen
implementados operaciones básicas como crear un objeto. Esta clase no puede ser
modificada en el modelo UML2 porque es una clase cuyos elementos son fijos y generados
en la transformación a código fuente.
97
Todos los elementos generados en el modelo destino, salvo la clase AbstractEntityService,
pueden ser modificados utilizando cualquier herramienta UML2 compatible con la
implementación UML2 de la plataforma Eclipse. Esta implementación se basa en el EMF
(Eclipse Modeling Framework) [52]. En el caso del modelo de esta segunda transformación
el perfil Ejb3.1-JPA2 debe estar incorporado en la lista de perfiles o metamodelos de la
herramienta para poder trabajar. El desarrollador puede agregar o quitar anotaciones o
modificar las propiedades de las anotaciones para generar código fuente más detallado.
Figura 4.40 Componentes del paquete Business con Anotaciones
En la figura 4.41, las clases del paquete entities que son anotadas como <<Entity>> en el
modelo origen son marcadas con la anotación JavaEE-JPA2 <<Entity>>. Estas clases luego
son transformadas en entidades cuyas instancias se pueden persistir en una base de datos.
La clase EntityGeneral se utiliza para permitir que las entidades creadas en el paquete
puedan heredar atributos comunes a todas las entidades como el atributo que determina si
una instancia de una clase está activa o no. Esta clase no puede ser modificada en el modelo
UML2 porque es una clase cuyos elementos son fijos y generados en la transformación a
código fuente.
Producto de la transformación se generan atributos en el modelo destino vinculados con las
asociaciones agregadas en el modelo UML2 origen. Por ejemplo, en la entidad DataStore1
se crea el atributo dataStore1Item de tipo DataStore1Item con anotación <<Association>> ,
98
de tipo OneToMany. Esto representa una asociación Uno a Muchos entre las instancias de
la entidad DataStore1 y la entidad DataStore1Item.
Figura 4.41 Componentes del paquete Entities con Anotaciones
4.3.2 Perfil Java EE
El metamodelo oficial y perfil UML de la OMG es para la especificación EJB versión 1. La
tecnología EJB cambia radicalmente de la versión 1 a la 3. Entonces es necesario utilizar un
perfil acorde con la especificación 3.1 por las ventajas que está ofrece. Como parte de este
trabajo se elabora un perfil para la plataforma Ejb 3.1-Web Services (JAX-WS) en base a la
información provista por The Java EE 7 Tutorial [8]. En la figura 4.42, se presenta el perfil
JavaEE que contempla las tecnologías Ejb 3.1 y Web Services (JAX-WS).
99
Figura 4.42 Perfil Ejb 3.1-Web Services
Los Enterprise Java Beans (EJB) son componentes del lado del servidor que encapsulan la
lógica del negocio de una aplicación; en la sección 2.5 se explica en detalle el tema. Como
se explica en el Anexo 2 (sección A.2.4), un perfil UML permite extender al metamodelo
de UML. Es decir, se puede especializar un subconjunto de UML 2 mediante el uso de
estereotipos, restricciones y valores etiquetados. En la figura 4.42, en base al elemento ya
existente en el metamodelo UML 2 con nombre Class se extiende el estereotipo
EnterpriseBeans. A partir de este estereotipo y siguiendo la teoría de Java EE se definen los
dos tipos de Enterprise Beans: Session y Message-driven que especializan al estereotipo
EnterpriseBeans. Luego el estereotipo Session generaliza a los elementos: Stateless,
Statefull y Singleton. Del elemento Interface se extienden los estereotipos: Remote y Local.
De Class extiende el elemento WebService y del elemento Operación extiende el
estereotipo: WebMethod. Estos estereotipos pueden ser aplicados al elemento UML 2
correspondiente agregando el detalle necesario para convertirlo en un modelo específico de
la plataforma.
4.3.3 Perfil JPA2
En la sección 2.5.4, se explica el API de Persistencia de Java (JPA 2). El perfil JPA 2 usado
en esta tesis se basa en el perfil propuesto por ge-nesez.org [54]. En la figura 4.43, se
muestra el perfil JPA 2 donde se definen las extensiones definidas como estereotipos que
son aplicadas sobre los elementos del modelo a extender por el perfil. En el caso del
elemento del metamodelo Class, se extiende el estereotipo Entity, que aplicado luego sobre
una clase del modelo permite generar una clase persistente. Esto se realiza como producto
de la transformación del modelo específico de la plataforma a código fuente JavaEE. Para
las propiedades y operaciones de UML 2 se definen estereotipos como: Association y
JoinColumn. Association se aplica en las propiedades generadas para representar los
distintos tipos asociaciones entre las entidades. JoinColumn sirve para especificar que el
atributo representa un campo de la tabla que actúa como clave foránea.
100
Figura 4.43 Perfil JPA2
4.3.4 Transformaciones del paquete Business
Esta transformación toma las clases del paquete Business con la anotación
<<WeServices>> y las transforma en clases UML con el estereotipo <<Stateless,
WebService>>. Estas clases heredan métodos generales de la clase AbstractEntityService
que es creada para ayudar a la generación de métodos básicos como crear o modificar
objetos.
Por cada operación anotada en el modelo origen con el estereotipo independiente de la
tecnología <<WebMethod>> la transformación genera los métodos correspondientes en el
destino con la anotación <<WebMethod>> del perfil JavaEE. También genera una interface
con estereotipos <<remote>> y <<local>> con sus respectivos métodos.
En la tabla 4.11 y en las figuras 4.44 y 4.45, se explican las transformaciones en el paquete
business. El código fuente de la relación se puede ver en el anexo 4.
Tabla 4.11 Transformación de elementos en el paquete business.Vista textual.
Modelo Origen Reglas de Transformación Modelo Destino
uml:Class (con
anotaciones
independientes de la
tecnología).
Se crea en el modelo destino una
clase AbstractEntityService.
El elemento Class de UML se
transforma en un elemento Class
en el modelo destino con
anotaciones <<Stateless,
WebService>>.
A cada elemento Class se le
agrega una relación de
generalización con un clase
AbstractEntityService.
Se crean interfaces <<remote>>
y <<local>> por cada clase.
Las operaciones marcadas con
anotaciones independientes de la
plataforma se vuelven anotar con
las mismas anotaciones en el
modelo destino.
uml:Class Clase
AbstractEntityService
uml:Class (con anotaciones
Stateless y WebService).
uml:Interface con
anotaciones Local y
Remote.
uml::Operations. Con
anotaciones: create, update,
deactivate, search.
En la figura 4.44, se muestra la transformación entre el modelo origen y el destino mediante
modelos gráficos del estándar XMI.
101
Figura 4.44 Transformación de elementos en el paquete business. Vista XMI.
102
Figura 4.45 Transformación de elementos en el paquete business. Vista UML 2.
En la figura 4.46, se puede observar la relación ClassToSession que realiza las
transformaciones explicadas en la tabla 4.11 y en las figuras: 4.44 y 4.45. Se puede ver
como en la cláusula enforce se invocan a varias relaciones. La relación InterfaceAnotada
crea una Interface por cada clase Stateless y una relación de generalización con la clase
AbstractEntityService que es única en el modelo. Mediante la relación InterfaceAnotada se
aplican las anotaciones <<Local>> y <<Remote>>. Mientras que con la relación
OperacionesInterfaces se crean las operaciones en las interfaces.
103
Figura 4.46 Código fuente de la relación ClassToSession. Vista QVT Relations.
La relación OperacionesClases cuya invocación está en la sección where de la figura 4.46
se puede observar en la figura 4.47. Esta relación genera las operaciones con sus
componentes en las clases del modelo destino. Las relaciones llamadas en la sección where
como OperacionWebMethod, verifican que exista en el modelo origen operaciones
marcadas con el estereotipo WebMethod para generar en el modelo destino operaciones
marcadas con el estereotipo WebMethod dependiente de la tecnología Java EE.
En el caso de las relaciones OperacionIndependienteCreate,
OperacionIndependienteUpdate, OperacionIndependienteDeactivate y
OperacionIndependienteSearch; si detecta que hay una operación anotada con alguno de los
estereotipos independientes: Create, Update, Deactivate o Search genera la operación con
las mismas anotaciones en las operaciones destino. Estas anotaciones sirven para que en la
transformación a código fuente se puedan generar instrucciones que permitan la realización
de operaciones básicas sobre los objetos.
104
Figura 4.47 Código fuente de la relación OperacionesClases. Vista QVT Relations.
4.3.5 Transformaciones del paquete Entities
Las clases del paquete Entities son transformadas en clases con la anotación <<Entity>>. A
las asociaciones entre clases se les agrega el estereotipo <<Association>> y mediante el
atributo AssociationType, se define la cardinalidad: one-to-one, one-to-many, many-to-one,
o many-to-many según corresponda.
La relación ClassToEntity transforma las clases con sus componentes en entidades anotadas
con el estereotipo <<Entity>>. En la tabla 4.12 y en las figuras 4.48 y 4.49, se explica la
transformación.
Tabla 4.12 Transformación de Clases del Paquete entities.Vista textual.
Modelo Origen Reglas de Transformación Modelo Destino
uml:Class (con
anotaciones
independiente de la
tecnología).
El elemento Class de UML2 con
anotaciones independiente de la
tecnología se transforma en un
elemento Class en el modelo
destino con anotaciones
<<Entity >>.
uml:Class (con anotaciones
Entity del perfil JavaEE-
JPA2).
105
Figura 4.48 Transformación de Clases del Paquete entities. Vista XMI.
En la figura 4.49 se observa el código fuente de la relación ClassToEntity que transforma
una clase en una entidad con anotación Entity.
106
Figura 4.49 Transformación de Clases del Paquete entities.. Vista QVT Relations.
Una relación importante que se define en la restricción where de la figura 4.49, es la de
Asociaciones. Está relación toma las asociaciones del modelo UML2 origen y genera las
mismas en el modelo destino con el agregado de atributos correspondientes en el modelo
destino para satisfacer la asociación según los requerimientos de la plataforma Java
Persistence API (JPA). La ventaja principal de esto es permitirle al usuario poder modificar
las asociaciones en el modelo origen de forma tal que la generación a código fuente Java
EE sea directa y con mayor nivel de detalle. La relación entre entidades es explicada en
detalle en la sección 2.5.4.
Como se muestra en la figura 4.50, como producto de la transformación el estereotipo
<<Association>> es aplicado a los atributos que representan una relación entre entidades.
107
Figura 4.50 Transformación de asociaciones en paquete Entity
En la figura 4.51, se muestran los atributos del perfil asociación aplicado a una propiedad
cuyo estereotipo es generado a partir de la transformación. En este caso es una asociación
direccional Uno a Muchos entre los objetos de las entidades DataStore1 y DataStore1Item.
Por defecto se marca como perezosa (LAZY) la relación.
Figura 4.51 Atributo marcado con el estereotipo <<Association>>
El código fuente de las transformaciones usando el lenguaje QVT se puede ver en el Anexo
4.
4.4 Transformación de modelo UML2 con perfil Ejb3.1-JPA2 a
Código Fuente JavaEE
En esta sección, se explican las reglas de transformación propuestas de UML 2 con
estereotipos del perfil EJB 3.1-JPA 2 a código fuente. El código fuente generado se
compone por los elementos de la capa del negocio Java EE. Las dos primeras
transformaciones se realizaron con el lenguaje relations que forma parte de
Query/Views/Transformations como se vio en la sección 4.2 y 4.3. En esta última
transformación se utiliza la herramienta Acceleo [9], que se basa en el lenguaje MTL
definido en la especificación de la OMG MOFM2T [10], como se explica en la sección
2.3.5.
108
En general el módulo de transformación de código fuente utilizando la herramienta
Acceleo, recorre cada uno de los elementos del modelo UML 2 origen y produce el código
fuente teniendo en cuenta los artefactos UML 2 y sus estereotipos relacionados.
Se divide la generación de código en cuatro secciones: en la sección 4.4.1 se muestra un
ejemplo, en la sección 4.4.2 se describen las características y funcionamiento general del
proyecto desarrollado con la herramienta Acceleo, en la sección 4.4.3 se analizan las
transformaciones del paquete business y en la sección 4.4.4 las transformaciones del
paquete entities.
4.4.1 Ejemplo de UML2 con perfil Ejb3.1-JPA2 a Código Fuente JavaEE
En base al modelo obtenido producto de la transformación de UML 2 con perfil
independiente de la tecnología a UML 2 con perfil Ejb3.1-JPA2, desarrollado en la sección
4.3, el desarrollador puede agregar, modificar o eliminar los elementos que considere
necesario al modelo UML 2 generado para cumplir con los requerimientos de los usuarios.
Se pueden aplicar estereotipos del perfil independiente de la tecnología y del perfil Ejb3.1-
JPA 2 sobre los elementos que considere necesario. Siguiendo el ejemplo planteado en la
sección 4.3.1, desde la figura 4.52 hasta la 4.59, se puede observar el modelo UML 2 origen
con anotaciones y parte del código fuente resultante de la aplicación de la transformación
con la herramienta Acceleo.
En la figura 4.52, se puede observar el diagrama UML 2 con las clases anotadas contenidas
en el paquete business. En la figura 4.53, se muestra el código fuente Ejb3 que se obtiene
en base al modelo UML2 de la interface. En la figura 4.54, se muestra el resultado de tomar
el modelo UML 2 de la clase Stateless y convertirla en código fuente Ejb3. En la figura
4.55, se puede observar la clase AbstractEntityService desde donde las demás clases
heredan los métodos que permiten realizar las operaciones básicas como: create (crear un
objeto) o update (actualizar un objeto).
109
Figura 4.52 Diagrama de Clases UML 2 con perfil Ejb3.1-JPA2 del paquete business
Figura 4.53 Interface generada con Acceleo
Figura 4.54 Clase Stateless generada con Acceleo
Figura 4.55 Clase AbstractEntityService generada con Acceleo
En la figura 4.56, se puede ver el diagrama UML 2 con las clases anotadas contenidas en el
paquete entities. En las figura 4.57, 4.58 y 4.59, se puede observar el código fuente que se
obtiene en base al modelo de las entidades DataStore1, DataStore1Item y Lane2. Se omiten
los métodos get y set generados en cada clase.
110
Figura 4.56 Diagrama de Clases UML 2 con perfil Ejb3.1-JPA2 del paquete entities
Figura 4.57 Entidad DataStore1 generada con Acceleo
Figura 4.58 Entidad DataStore1Item generada con Acceleo
111
Figura 4.59Entidad Lane2 generada con Acceleo
4.4.2 Estructura del Proyecto Acceleo
En este punto se explican los componentes principales del proyecto para la transformación
del modelo UML 2 con anotaciones a código fuente Java EE. En la figura 4.60, podemos
ver la estructura del proyecto Acceleo con la descripción de sus principales componentes.
Como se explicó en la sección 2.3.5 los componentes principales de la herramienta para la
generación de código Acceleo son: los módulos, las plantillas y las consultas. Los módulos
están compuestos por plantillas y consultas. Un módulo depende generalmente de otros
módulos para su ejecución y se pueden invocar plantillas. Los módulos utilizan una
implementación del lenguaje MTL y en casos muy específicos pueden acceder a código
fuente java estándar. Las plantillas son un conjunto de instrucciones para generar texto y las
consultas son utilizadas para extraer información de un modelo.
Figura 4.60 Estructura con los principales componentes del proyecto Acceleo
El módulo principal es el definido en el paquete main con el nombre generate.mtl. Como se
puede observar en la figura 4.61, la plantilla generatePackage del módulo generate.mtl
112
utiliza la declaración for para recorrer cada uno de los elementos del modelo UML2 origen.
Luego dentro de la estructura repetitiva llama a la plantilla que corresponda para generar el
archivo con el código fuente java de cada componente JavaEE.
Figura 4.61 Plantilla generarPackage
Dentro del componente generatePackage se invoca a la plantilla generateWebService que
se muestra en la figura 4.62. Esta plantilla toma a las clases del modelo origen anotadas con
el estereotipo 'WebService' y las transforma en clases java EE del tipo Stateless con las
anotaciones correspondientes.
La plantilla _commentFileBlock() genera comentarios en el archivo de la clase generada.
La plantilla packageBlock() genera el nombre del paquete al comenzar la clase java. La
plantilla importBlock genera las líneas de código con los paquetes a importar para que
pueda funcionar la clase. Mientras que la plantilla _commentBodyBlock() genera
comentarios sobre la clase. Finalmente, la plantilla generateBodyWebService() se explica
en la sección 4.4.3: “Transformaciones del Paquete Business”.
113
Figura 4.62 Plantilla generateWebService
Desde las instrucciones del componente generatePackage de la figura 4.61, se llama a la
plantilla generateEntity que se puede observar en la figura 4.63. Esta plantilla toma a las
clases del modelo origen anotadas con el estereotipo 'Entity' y las transforma en entidades
javaEE persistentes con las anotaciones correspondientes. En la sección 2.5.4 se explica el
api de persistencia de java.
En el interior del código de generateEntity, la plantilla packageBlock() genera el nombre
del paquete al comenzar la clase java. El componente importBlock genera las líneas de
código con los paquetes a importar para que pueda funcionar la entidad. Mientras que la
plantilla generateBodyEntity() se explica en la sección 4.4.4 “Transformación del Paquete
Entities”.
Figura 4.63 Plantilla generateEntity
4.4.3 Transformaciones del Paquete Business
En base al modelo UML 2 con perfiles EJB3.1-JPA2 generado en la sección 4.3.4 se
explica la transformación a código fuente javaEE del paquete business.
114
En la figura 4.64, se muestra el modelo XMI que se utiliza como origen de la
transformación. Está compuesto por los siguientes elementos: la clase abstracta
“AbstractEntityService” de la cual heredan métodos las clases del paquete Business, las
clases SesionBeans anotadas como WebService y/o Stateless y la interface anotada como
local y remote que es implementada por los SesionBeans. A su vez los SessionBeans tienen
operaciones que pueden estar marcadas con la anotación WebMethod para ser expuestas
como operaciones de un Web Services.
Figura 4.64 Diagrama XMI origen con los componentes del paquete Business
Desde la plantilla generateWebService de la figura 4.62, se invoca al componente
generateBodyWebService. Las partes principales de la plantilla se muestran en la figura
4.65 y 4.66. En la figura 4.65, se puede observar que la plantilla genera la anotación
Stateless si existe el estereotipo en la clase. Además se genera la anotación WebService y la
declaración de la clase según lo definido en el modelo UML2 origen.
115
Figura 4.65 Plantilla generateCuerpoWebService del módulo cuerpoWebService
En la figura 4.66, se muestra la generación automática de los métodos de las clases del
paquete Business. Se puede ver que en el caso que la operación de la clase UML2 este
marcada con el estereotipo “Create” se genera una instrucción de código java que permite
crear un objeto de la clase correspondiente. Esta instrucción utiliza el método créate de la
clase que extiende. En la figura 4.67, se muestra el método.
Figura 4.66 Generación de métodos de las clases del paquete Business
Figura 4.67 Método create de la Clase AbstractEntityService
116
En la figura 4.68, se puede ver el resultado de una parte de la transformación. Se puede
apreciar que la clase Lane2Service es transformada en una clase java que implementa la
interface Lane2ServiceInterface y hereda de la clase AbstractEntityService. La clase java es
anotada como Stateless y WebService y se genera el código del único método existente en
la clase UML que es anotado como WebMethod para que sea expuesto a través de un Web
Services.
Figura 4.68 Transformación de una clase a código fuente JavaEE
4.4.4 Transformación del Paquete Entities
En base al modelo generado en la sección 4.3.5 se explica la transformación a código
fuente javaEE del paquete Entities.
En la figura 4.69, se muestra el modelo XMI que se utiliza como origen de la
transformación. Está compuesto por: la clase EntityGeneral, las entidades resultantes y los
estereotipos del perfil independiente de la plataforma y EJB 3.1-JPA 2. Las entidades a su
vez están compuestas por atributos, asociaciones y relaciones de generalización con la clase
EntityGeneral.
117
Figura 4.69 Diagrama XMI origen con los componentes del paquete entities
Desde la plantilla generateEntity de la figura 4.63, se invoca a la plantilla
generateBodyEntity() si existe el estereotipo en la clase del modelo UML2 origen. Las
partes principales de la plantilla se muestran en la figura 4.70 y 4.71. En la figura 4.70, se
puede observar que la plantilla genera la anotación “Entity” y la declaración de la clase
persistente.
Figura 4.70 Plantilla generateCuerpoEntity del módulo cuerpoEntity
En la figura 4.71, se observa como la herramienta toma los atributos marcados con el
estereotipo “Association” y los convierte en anotaciones vinculadas a los atributos de una
clase persistente java.
118
Figura 4.71 Anotación de propiedades con relaciones entre objetos
En la figura 4.72, se puede ver el resultado de la transformación de la clase DataStore1,
donde se destaca la asociación OnetoMany con la entidad DataStore1Item. Se puede ver en
la figura con una llave la relación “OnetoMany” entre los objetos de la clase DataStore1 y
los objetos de la clase DataStore1Item.
Figura 4.72 Resultado de la transformación de las clase DataStore1
119
El código fuente de las transformaciones usando la herramienta Acceleo se puede ver en el
Anexo 5.
4.5 Conclusiones
En este capítulo se han presentado los principales componentes de las transformaciones que
permiten cumplir con el objetivo de generar en forma automática y/o semiautomática
modelos de procesos ejecutables definidos con el estándar BPMN 2 a componentes Java
EE.
Las transformaciones de modelos se desarrollan utilizando el estándar QVT-Relations y se
realizan en el contexto de la arquitectura de metamodelos MOF (Meta Object Facility). Los
metamodelos utilizados son los de BPMN 2 y UML 2 que se explican en los anexos 1 y 2.
En las secciones 4.2, 4.3, y 4.4 de este capítulo se explican las transformaciones propuestas.
Para realizar las transformaciones se utiliza la herramienta Medini QVT y Acceleo.
Se parte de un diagrama BPMN 2 ejecutable y a través de transformaciones se obtienen
componentes Java Enterprise. El modelo BPMN 2 ejecutable se transforma a un modelo
UML 2 con anotaciones de un perfil independiente de la tecnología. El perfil independiente
de la plataforma se explica en la sección 4.2.2. En base al modelo obtenido producto de la
transformación de BPMN 2 a UML 2 el desarrollador puede hacer modificaciones sobre los
elementos del modelo UML 2. Puede agregar estereotipos del perfil independiente de la
plataforma, atributos, operaciones, clases y asociaciones entre las clases.
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. Se utiliza como
metamodelo MOF fuente UML2 y como Metamodelo MOF destino a UML 2 con la
aplicación del perfil JavaEE-JPA2. El metamodelo fuente y destino es el mismo y se
explica en el anexo 2. Se utiliza perfiles dependientes de la plataforma (JavaEE-JPA2), que
se explica en las secciones 4.3.2 y 4.3.3. Como en la primer transformación el desarrollador
puede modificar los componentes del modelo UML 2 generado para poder cumplir con la
funcionalidad requerida. Se puede modificar y aplicar nuevos estereotipos del perfil
independiente de la tecnología y también del perfil específico de la plataforma sobre los
elementos que se considere necesario.
Finalmente, del modelo UML 2 específico de la plataforma se generan los componentes de
código fuente Java EE. En esta última transformación se utiliza la herramienta Acceleo, que
se basa en el lenguaje MTL definido en la especificación de la OMG MOFM2T. En la
sección 4.4.2, se explica la estructura del proyecto y los principales componentes. El código
fuente generado es funcional y se puede desplegar en cualquier servidor compatible con
Java EE.
El objetivo del capítulo ha sido explicar que partir de un modelo de proceso utilizando el
estándar BPMN 2, se puede generar modelos de diseño UML 2 estándares y en base este
código fuente. El desarrollo utilizando las transformaciones propuestas trabaja en distintos
niveles de abstracción desde un modelo de proceso hasta llegar a un modelo dependiente de
120
la plataforma que se puede convertir en código fuente. En cada transformación se obtiene
un modelo que se encuentra relacionado con un proceso del negocio que a su vez se
encuentra alineado con los requerimientos de los usuarios.
Se logra la consistencia entre procesos del negocio ejecutables, los modelos del diseño, y el
software que automatiza a estos procesos. Esto último permite mejorar la calidad del
desarrollo del software al quedar alineados desde los componentes cercanos a la
especificación de requerimientos pasando por los modelos intermedios del diseño y
llegando al nivel de concreción más alto expresado en código fuente ejecutable. Esta
alineación permite disminuir la cantidad de errores entre los requerimientos planteados por
el usuario y lo que realiza el software.
Las transformaciones permiten aumentar la productividad en el desarrollo ya que generan
rápidamente un prototipo que puede ser modificado por el desarrollador. Los modelos
UML 2 pueden ser marcados con estereotipos pertenecientes a los perfiles diseñados para
permitir generar modelos y código con mayor nivel de detalle.
En el próximo capítulo se explica la aplicación del método de trabajo sobre un caso de
estudio.
121
5. Aplicación del Método de Trabajo y
Casos de Estudio
En este capítulo se describe como se ha aplicado el método de trabajo iterativo e
incremental presentado en la sección 1.3 del capítulo 1. Se presenta también uno de los
casos de estudio que se ha utilizado para validar la aplicación de las transformaciones con
un caso real. El problema propuesto demuestra el funcionamiento de las transformaciones
que son el objetivo principal de esta tesis de maestría. En base a los casos de estudio
desarrollados se han aplicado refinamientos y mejoras, resultando como producto las
versiones finales de las transformaciones. En el anexo 3, se explica otro caso real: el
sistema de guardia hospitalaria.
5.1 Aplicación del Método de Trabajo
La creación de las transformaciones para generar un prototipo Java EE ha sido un proceso
continuo, iterativo e incremental que ha pasado por varias etapas de refinamiento y
validación hasta llegar a la versión actual presentada en este documento de tesis. Teniendo
en cuenta el método de trabajo explicado en la sección 1.3 del capítulo 1, a continuación se
explica las transformaciones desarrolladas teniendo en cuenta las particularidades de cada
una y con el objetivo de describir el proceso de validación aplicado en cada instancia de las
iteraciones realizadas. En la figura 5.1, se pueden observar los pasos de una iteración para
obtener una transformación. En la sección 1.3 del capítulo uno se explica la metodología de
trabajo. En las secciones 5.1.1, 5.1.2 y 5.1.3, se sigue la numeración y los pasos que se
muestran en la figura 5.1.
122
Figura 5.1 Pasos de una Iteración para obtener una Transformación
5.1.1 Método de Trabajo Aplicado a la Transformación de BPMN 2 a
UML 2 con perfil independiente de la plataforma
A continuación se explican las etapas del método utilizado en la primera transformación en
base al flujo de la figura 5.1.
A.1 Diseñar el Modelo BPMN (Origen)
Utilizando la Herramienta Camunda BPMN 2.0 Modeler [57] se elaboran los diagramas
que se utilizan como origen de las transformaciones. La herramienta genera un archivo en
formato bpmn2 que debe ser convertido por medio de una transformación XSLT
(eXtensible Stylesheet Language Transformations) a un archivo con formato XMI que
pueda ser procesado por la herramienta de transformación QVT. El modelo BPMN 2 está
basado en el estándar de la OMG y puede ser desplegado en motores BPMS existentes en el
mercado como el provisto por Camunda.
B Crear la Transformación
Se crea la transformación de BPMN 2 a UML 2 con perfil independiente de la plataforma
utilizando el lenguaje QVT y la herramienta Medini QVT. Para poder lograr el objetivo se
estudiaron y elaboraron informes sobre los metamodelos de la OMG: BPMN 2 y UML 2.
También se creó un perfil independiente de la plataforma que se aplica al modelo UML 2
destino de la transformación.
123
C Probar la Transformación (Validar la transformación)
En base a los objetivos definidos para la transformación el grupo de expertos crea un
modelo UML 2 con perfil independiente de la plataforma. Se verifican si son correctas las
relaciones entre los elementos del modelo generado por la transformación y los elementos
del modelo diseñado por expertos. El modelo generado por expertos se basa en los patrones
y estilos de modelado definidos en las transformaciones.
El grupo de expertos esta conformado por:
Ingeniero en Sistemas de Información. Gerardo Fuentes. Trabaja en la Dirección de
Informática de ls Ministerio de Salud de la Provincia de Mendoza.
Ingeniero en Sistemas de Información. Ricardo Cimarelli. Trabaja en el Hospital
Tagarelli de la provincia de Mendoza.
Analista de Sistemas. Tamara Fazio. Trabaja en el Hospital Regional Antonio J
Scaravelli de la provincia de Mendoza.
D Modificar la Transformación
En el caso de que no exista coincidencia entre el/los elemento/s del modelo origen y destino
se revisa la transformación y en base al o los errores detectados se modifica la
transformación para corregir los problemas.
Modelo UML 2 (Destino)
El modelo UML 2 obtenido como producto de la transformación contiene todos los
elementos definidos a partir de los objetivos de las transformaciones. Los elementos que
correspondan tienen aplicados el perfil independiente de la plataforma.
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
A continuación se explican las etapas del método utilizado en la segunda transformación en
base al flujo de la figura 5.1.
A.2 Iniciar desde Modelo UML 2 (Origen)
Se utiliza como origen el modelo UML 2 con perfil independiente de la plataforma
generado por la transformación anterior.
B Crear la Transformación
124
En base al modelo UML 2 con perfil independiente de la plataforma generado por la
transformación anterior se genera un modelo UML 2 con perfil independiente de la
plataforma JavaEE. La transformación se crea utilizando el estándar QVT. Se crea un perfil
JavaEE que se aplica en el modelo destino generado. Para poder lograr los objetivos se
elabora un informe sobre la transformación y sobre el perfil Java EE creado.
C Probar la Transformación (Validar la transformación)
En base a los objetivos definidos para la transformación el grupo de expertos crea un
modelo UML 2 con perfil JavaEE. Se verifican si son correctas las relaciones entre los
elementos del modelo generado por la transformación y los elementos del modelo diseñado
por expertos.
D Modificar la Transformación
En el caso de que no exista coincidencia entre el/los elemento/s del modelo origen y destino
se revisa la transformación y en base al error detectado se modifica la transformación para
corregir el problema.
Modelo UML 2 (Destino)
Como producto de la transformación se obtiene un modelo UML 2 con perfil Ejb3.1-JPA2.
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
A continuación se explican las etapas del método utilizado en la tercera transformación en
base al flujo de la figura 5.1.
A.2 Modelo UML 2
Se utiliza como origen el modelo UML2 con perfil JavaEE generado por la transformación
anterior.
B Crear la Transformación
Utilizando la herramienta Acceleo basada en el lenguaje MTL definido en la especificación
de la OMG MOFM2T [10] se define la transformación a código fuente Java EE. Se estudia
y elabora informe sobre la transformación.
C Probar la Transformación (Validar la transformación)
En base a los objetivos definidos para la transformación el grupo de expertos crea con la
herramienta eclipse los componentes de software Java EE que debería generar la
transformación. Se verifican si son correctas las relaciones entre los elementos del código
125
fuente generado por la transformación y los elementos del código fuente diseñado por
expertos.
D Modificar la Transformación
En el caso de que el código fuente generado no sea correcto se modifica la transformación
para corregir el problema.
Código Fuente Java EE (Destino)
El código fuente generado representa a los componentes del negocio Java EE y es el
producto final de las tres transformaciones sucesivas aplicadas. Se cumple el objetivo final
de transformar un proceso del negocio técnico BPMN 2 en componentes de software. El
código fuente está alineado con modelos UML 2 y este a su vez con un proceso del negocio
BPMN 2.
5.2 Versiones Desarrolladas de las Transformaciones
Una primera versión es presentada en [58] y consiste en la transformación automática de un
diagrama BPMN2 en componentes JavaEE. Se utilizan como herramientas QVT Relacional
y MOfScript. Se utilizan varios diagramas BPMN2 para validar la propuesta.
La segunda versión es presentada en [59] y a diferencia de la primera versión agrega las
transformaciones de BPMN 2 a UML2, la creación de perfiles UML 2 para las plataformas
JPA2- JavaEE y se utiliza la herramienta Acceleo para las transformaciones de UML 2 a
componentes Java EE.
La tercera versión es detallada en este documento de tesis de maestría; está basada en las
dos versiones anteriores agregando nuevas transformaciones, la incorporación de un perfil
independiente de la plataforma y la posibilidad de integración con motores BPMN 2
existentes en el mercado.
5.3 Casos de Estudio de Laboratorio y Reales
Para obtener la versión final de las transformaciones y perfiles desarrollados para cumplir
con los objetivos de este trabajo de tesis se ha trabajado sobre varios casos de estudio. Los
casos de estudios se pueden clasificar en casos de estudio genéricos o de laboratorio y casos
de estudio reales. En la tabla 5.1 se puede observar un detalle de los casos de estudio para
validar la propuesta de tesis.
Tabla 5.1 Casos de Estudio Tipo de Caso de Estudio Sigla Nombre del Caso de Estudio
Laboratorio C.L.1 Diagrama Genérico 1
C.L.2 Diagrama Genérico 2
C.L.3 Diagrama Genérico 3
126
Reales C.R.1 Sistema de Mantenimiento
C.R.2 Sistema de RAC Hospitalario (Anexo 3)
Para el desarrollo de los casos de estudio se utiliza el método de trabajo planteado en la
figura 5.1. A continuación se explica en que consiste cada tipo de caso de estudio:
Casos de Estudio Genéricos o de laboratorio
Estos casos de estudio se han creado utilizando como modelo inicial un diagrama BPMN 2
cuyos elementos están nombrados en forma genérica. Se diseñan de tal forma de
generalizar los escenarios de procesos de negocio que se puedan dar en la realidad. En base
a estos diagramas se hacen pruebas controladas de laboratorio con el fin de encontrar
problemas como errores o inconsistencias en los modelos destinos generados.
Casos de Estudio Reales
Los casos de estudio reales se elaboran en base a procesos del negocio que están
implementados en distintos dominios de aplicación. Los diagramas BPMN2 creados se
usan para evaluar el comportamiento de las transformaciones y de esta forma realizar las
correcciones necesarias para lograr modelos destino con la menor cantidad de errores
posibles. Se presentan dos casos reales: en el anexo 3, se explica el sistema de guardia
hospitalario y en la siguiente sección el sistema de mantenimiento.
5.4 Caso de Estudio del Sistema de Mantenimiento
En esta sección se desarrolla uno de los casos de estudio donde se aplicaron las
transformaciones propuestas, este caso se suma al caso genérico que se ha desarrollado en
las secciones del capítulo 4 y al caso real explicado en el anexo 3. Se aplica el método de
trabajo propuesto en la sección 1.3 del capítulo 1 para lograr el objetivo de que partiendo
desde un modelo técnico del negocio BPMN 2 se pueda obtener un prototipo conformado
por componentes de código fuente Java EE. Este es uno de los casos de estudio que se
utilizó para validar la propuesta de este trabajo de tesis y consiste en la implementación de
un sistema de mantenimiento correctivo.
5.4.1 Planteo del Problema
El caso real elegido para validar la propuesta es el desarrollo de un sistema de
mantenimiento correctivo para el Hospital Regional Antonio J. Scaravelli. En este
organismo público pueden surgir distintos tipos de solicitudes de reparación que pueden ser
derivadas a los siguientes sectores: Servicio de Mantenimiento, Departamento de
Bioingeniería o Departamento de Informática. En la figura 5.2, se explica en forma general
el proceso.
127
Figura 5.2 Esquema general del proceso de mantenimiento
En los siguientes nueve puntos se define el proceso del caso de estudio en forma detallada.
Mientras que en la sección 5.4.2 se explica el modelo BPMN 2 utilizado como origen de las
transformaciones.
1_ Un problema técnico o consulta le surge a un usuario de un sector de la
organización.
2_ El usuario carga la solicitud de reparación en el sistema de mantenimiento
para recibir soporte.
3_ El sector de soporte técnico recibe y acepta o rechaza la solicitud de servicio
técnico.
4_ El usuario es notificado por sistema que la solicitud de reparación fue
aceptada o rechazada.
6_ En el caso de ser aceptada la solicitud de reparación, el sector de soporte
técnico crea una orden de trabajo donde detalla las tareas a realizar, el nivel de
prioridad y los elementos necesarios para poder solucionar el problema.
7_ Una vez que la orden de trabajo es realizada el sector de soporte técnico cierra
la orden de trabajo.
8_ El usuario recibe por sistema la notificación de que la orden de trabajo fue
cerrada.
9_ El usuario del sector que creo la solicitud de reparación califica con una
escala y con observaciones el trabajo realizado.
128
5.4.2 Modelo del Proceso Técnico BPMN 2
El diseño del diagrama técnico BPMN 2 se elabora siguiendo el marco metodológico
BPMN-Framework [20] y buenas prácticas definidas en [60]. En la figura 5.3, se puede
observar que el modelo técnico BPMN 2 está formado por un Pool compuesto por dos
elementos Lane, donde solo se muestran los artefactos relacionados con la tecnología. Este
Pool puede interactuar con otros Pools donde se definan procesos manuales.
Figura 5.3 Diagrama Técnico BPMN2 del caso de estudio Sistema de mantenimiento
En la figura 5.4 se puede ver el diagrama de la figura 5.3 en formato gráfico del estándar
XMI. En la figura se han quitado los elementos conectores para facilitar su visualización. A
partir de este archivo XMI se realiza la primer transformación a un modelo UML 2 con
perfiles independiente de la plataforma.
129
Figura 5.4 Diagrama BPMN 2 con visualizador de formato xmi
5.4.3 Transformación de BPMN 2 a UML 2
En base a las transformaciones QVT y el perfil independiente de la tecnología definidos en
la sección 4.2.2 del capítulo 4 se genera el modelo UML 2 con perfil independiente de la
plataforma. Este modelo puede ser modificado por cualquier herramienta que cumpla con el
estándar UML 2 y estás modificaciones son tomadas por la transformación siguiente para
su procesamiento.
El modelo generado está compuesto por dos paquetes: el paquete entities y el business. En
el paquete entities se crean las clases que luego se van a convertir en entidades del negocio
(Entity). Las clases generadas dentro del paquete entities se muestran en el diagrama UML
2 de la figura 5.5.
130
Figura 5.5 Modelo resultante de la Transformación de un modelo BPMN 2.0 a un modelo
UML 2 del Paquete entities
En el paquete Business se crean las clases que luego se van a convertir en SessionBeans.
Las clases en el interior del paquete business se pueden observar en el diagrama XMI de la
figura 5.6.
131
Figura 5.6 Modelo resultante de la Transformación de un modelo BPMN 2.0 a un modelo
UML 2 del Paquete Business
5.4.4 Transformación de UML2 a UML2 con perfil Ejb3.1-JPA2
En base al modelo generado en la primer transformación se genera la segunda
transformación de un diagrama UML 2 con perfil independiente de la plataforma a un
diagrama UML 2 con perfil Java EE. En las figuras 5.7, 5.8, 5.9 y 5.10 se puede observar
que elementos como: clases, atributos, operaciones y asociaciones tienen anotaciones
específicas de la plataforma Java EE. En la sección 4.3 del capítulo 4, se describe en detalle
la Transformación de UML2 a UML2 con perfil Ejb3.1-JPA2.
Se puede observar en la figura 5.7, las asociaciones y entidades generadas a partir del
modelo UML2 origen. A diferencia del modelo origen al nuevo modelo se le aplica un
perfil dependiente de la tecnología utilizada, que en este caso es Java EE. La definición del
perfil JPA 2 se explica en el punto 4.3.3 del capítulo 4. Por ejemplo, las asociaciones entre
clases son anotadas con el estereotipo dependiente de la tecnología Association.
132
Figura 5.7 Modelo resultante de la Transformación de un modelo UML2 a un modelo
UML 2 del Paquete Entities
En la figura 5.8, se muestra la entidad SolicitudReparacion donde está el atributo
solicitudReparacionItem anotado con el estereotipo Association. También podemos
apreciar en la figura los atributos correspondientes a la anotación aplicada, donde la
transformación QVT generó los valores por defecto de los atributos Fetch y Type.
Figura 5.8 Perfil Association aplicado a la propiedad solicitudReparacionItem
133
Como se explica en la sección 4.3 del capítulo 4, está segunda transformación toma las
clases UML2 del paquete Business y genera a estas con anotaciones Stateless y
WebService. Además por cada clase se ha generado una interface para el acceso local y
remoto de los métodos implementados, las interfaces tienen aplicadas las anotaciones
<<Local,Remote>>.
La clases generadas en el paquete Business heredan de la clase AbstractEntityService. Esta
clase no puede ser modificada en el modelo UML 2 porque es una clase cuyos elementos
son fijos y son generados posteriormente en la transformación a código fuente.
En la figura 5.9 se muestran los componentes Java EE generados en el paquete business
como producto de la ejecución de la segunda transformación.
Figura 5.9 Componentes JavaEE del Paquete Business generados en la Segunda
Transformación
Las operaciones de las clases dentro del paquete business permanecen en el caso de las
operaciones básicas, marcadas con las anotaciones del perfil independiente: créate, update,
deactivate y search.
En el caso de las operaciones con anotaciones para permitir el acceso de los métodos vía
WebServices se le aplica la anotación WebMethod del perfil Java EE.
En la figura 5.10 se puede observar las operaciones de la clase SectorServiceSessionBean
generados por la transformación.
134
Figura 5.10 Detalle de los Componentes de la Clase SectorServiceSessionBean
5.4.5 Transformacion con Acceleo
La transformación definida con la herramienta Acceleo y explicadas en la sección 4.4 del
capítulo 4 se aplican al modelo UML 2 con perfiles Java EE. El destino de la
transformación son los componentes de código fuente Java EE que pueden desplegarse en
cualquier servidor de aplicaciones compatible con el estándar. Estos componentes Java EE
integran a un prototipo que es el producto final de las transformaciones propuestas.
En la figura 5.11, puede observarse la estructura de elementos generados para el caso de
estudio. Los elementos generados tienen una alta trazabilidad con el modelo UM L2
dependiente de la plataforma, con el modelo UML 2 independiente de la plataforma y con
el modelo de procesos técnico BPMN 2. Esta trazabilidad que permite el método empleado
es un buen indicador de alineamiento entre procesos del negocio y el software que
automatiza esos procesos.
135
Figura 5.11 Estructura de elementos Java EE generados por la transformación Acceleo
En la figura 5.12 se muestra un ejemplo de una parte de la transformación a código fuente
Java EE. En la parte de arriba de la figura está definida la clase SectorServiceSessionBean
que tiene anotaciones Stateless y Webservice, una relación de asociación con la clase
AbstractEntityService y de realización con la clase SectorServiceInterface. La clase está
compuesta por una operación con nombre agregarSolicitudReparacion marcada con la
operación de creación de objetos Create. Esta operación tiene como parámetro una clase de
tipo SolicitudReparacion. En la parte de abajo de la figura 5.13 podemos ver que la
transformación Acceleo genera el código Java EE teniendo en cuenta los elementos del
modelo origen y sus anotaciones relacionadas.
136
Figura 5.12 Ejemplo de Código Fuente Generado para Clase Stateless
En la figura 5.13, podemos observar el resultado de la transformación de una Clase con
estereotipo Entity a una Clase Entity JavaEE que puede ser persistida en una tabla con
nombre OrdenTrabajo. Se puede ver también en la figura que se genera el código extend
relacionado con la relación de Generalización especificada en el modelo origen. Las
asociaciones del modelo origen son transformados en atributos con anotaciones como
@OneToMany de acuerdo a como se definen las asociaciones con el estándar de
persistencia de java JPA2.
Figura 5.13 Ejemplo de Código Fuente Generado para Clase Entity
5.5 Conclusiones
En este capítulo se ha presentado por una parte la descripción de la aplicación del método
de trabajo definido en la sección 1.3 del capítulo 1 y por otro lado un resumen del caso de
estudio real sobre el que se han aplicado las transformaciones desarrolladas en este trabajo
de tesis. En el anexo 3, se presenta un segundo caso de estudio real, consistente en el
desarrollo de un sistema de guardia hospitalario.
Se describe la aplicación del método de trabajo utilizado, el proceso de desarrollo de las
transformaciones QVT, las iteraciones realizadas, el mecanismo de validación, los
estándares y herramientas utilizadas y los elementos diseñados para cumplir con los
objetivos planteados.
137
Se muestra como las versiones finales de las transformaciones y perfiles creados han
pasado por varias etapas de refinamiento y validación. Se explican los casos de laboratorio
y reales utilizados para demostrar el funcionamiento de las transformaciones.
El objetivo del capítulo ha sido demostrar la validación de las tres transformaciones
desarrolladas para cumplir con el objetivo de la tesis de transformar en forma automática
y/o semiautomática modelos de procesos ejecutables definidos con el estándar BPMN 2 a
componentes Java EE.
En el próximo capítulo se presentan las conclusiones de esta tesis.
138
6. Conclusiones
En este capítulo se presentan las conclusiones de este trabajo de Tesis de Maestría y las
líneas de trabajo futuras. En primer lugar, en la sección 6.1, se analizan los resultados
obtenidos. Posteriormente, en la sección 6.2, se explican los principales aportes y
publicaciones. En la sección 6.3, se exponen las líneas de trabajo futuras y por último en la
sección 6.4 las conclusiones finales.
6.1 Resultados Obtenidos
Los resultados obtenidos en este trabajo de tesis de maestría, son los productos obtenidos
de la definición de: las transformaciones, perfiles y el método de trabajo empleado. En
síntesis, con este trabajo de tesis se logra obtener modelos UML 2 y componentes de
código fuente Java EE alineados con los procesos del negocio de la organización.
La propuesta se puede extender a otros proyectos debido a que se utilizan estándares
abiertos, plataformas y herramientas open source. El modelo UML 2 y el código generado
es un prototipo que sirve de base para que en posteriores iteraciones se logre un producto
completo.
El aporte a la ingeniería de software son: las transformaciones, perfiles y un método de
trabajo para mejorar la calidad y la productividad en el desarrollo de software en el marco
de la arquitectura dirigida por modelos.
A continuación se explica con más profundidad los resultados alcanzados:
Perfil UML independiente de la tecnología.
Se define un perfil independiente de la tecnología que puede ser aplicado sobre un
modelo de clases UML 2. El perfil no contiene elementos específicos de una
tecnología o plataforma concreta. Los resultados obtenidos con la definición y la
aplicación del perfil brinda los siguientes beneficios al desarrollador y a las
transformaciones propuestas:
Facilita la transformación automática a un modelo específico de la
plataforma o directamente a componentes de código fuente. Utiliza las
anotaciones sobre los elementos del modelo UML 2 para dar más
información a las transformaciones QVT y generar modelos más detallados.
Se utiliza en forma transversal en las tres transformaciones para lograr el
objetivo final de facilitar la generación del código fuente. Se utiliza en la
primera transformación para generar elementos en el modelo destino al
139
marcarlo con anotaciones. La segunda transformación toma las anotaciones
sobre los elementos y los replica en el modelo destino. Finalmente la última
transformación aplica las anotaciones independientes de la tecnología sobre
los elementos para generar el código fuente.
En base a las características de los elementos del modelo BPMN 2 la primer
transformación puede crear automáticamente elementos del modelo UML 2
destino marcados con anotaciones.
El desarrollador puede modificar o agregar anotaciones del perfil
independiente de la tecnología sobre el modelo UML 2. Estas anotaciones
son tomadas por las transformaciones y utilizadas en la generación de
nuevos elmentos.
Se contribuye a mejorar la evolución de modelos abstractos a modelos con
mayor nivel de detalle o directamente generar componentes de software a
partir del modelo con anotaciones.
En la sección 4.2.2, se muestra la definición del perfil Independiente de la
Tecnología.
Perfiles UML 2 específicos de la plataforma.
Se definen perfiles para la plataforma Ejb 3.1-Web Services (JAX-WS) y para el
para API de Persistencia de Java (JPA 2). Los resultados obtenidos con la definición
y la aplicación de los perfiles brindan los siguientes beneficios al desarrollador y a
las transformaciones propuestas:
Se puede extender a otros proyectos de desarrollo porque se diseñan en base
al estándar UML 2 para la creación de perfiles.
Brindan la posibilidad de anotar elementos del modelo UML 2 para
convertirlo en un modelo específico de la plataforma Java EE.
En base a las anotaciones aplicadas sobre los elementos del modelo se
obtiene mayor nivel de detalle que permite facilitar la transformación en
forma automática a código fuente Java EE.
La segunda transformación propuesta mejora la productividad del
desarrollador al generar automáticamente modelos UML 2 anotados con
estos perfiles específicos de la plataforma.
El desarrollador puede modificar o agregar anotaciones de los perfiles
específicos de la plataforma sobre los elementos del modelo UML 2.
En resumen, se facilita la tarea del desarrollador al permitirle aplicar los perfiles
específicos de la plataforma sobre los modelos para obtener rápidamente código
fuente que se puede ejecutar en un servidor de aplicaciones JavaEE.
140
En las secciones 4.3.2 y 4.2.3, se puede observar la definición de los perfiles
JavaEE.
Transformación de un modelo técnico BPMN 2 a un diagrama de clases UML2.
El desarrollo de esta transformación permite generar a partir de un modelo de
procesos técnico BPMN 2 un modelo UML 2 con anotaciones independientes de la
tecnología. Los resultados obtenidos con la definición y la aplicación de la
transformación brinda los siguientes beneficios:
Se trabaja con un metamodelo BPMN 2 estándar que da la posibilidad de la
la integración del modelo BPMN 2 origen en alguno de los sistemas de
gestión de procesos del negocio Open Source existentes en el mercado.
Se demuestra que a partir de la información contenida en un diagrama
BPMN 2.0 ejecutable se puede obtener un modelo UML2 compuesto por
paquetes y clases.
El modelo destino de la transformación tienen aplicado las anotaciones de un
perfil independiente de la tecnología para facilitar las posteriores
transformaciones. La transformación anota distintos elementos del modelo
como las clases que van a persistir objetos o las operaciones de las clases
que se van a exponer a otras aplicaciones utilizando algún tipo de servicio
web. Para hacer esto, estima los elementos en el modelo UML 2 destino que
se tienen que anotar en base a la información provista por los elementos del
modelo BPMN 2 origen.
El modelo UML 2 resultado de la transformación está compuesto por
elementos que le brindan una base al desarrollador para construir un diseño
orientado objetos alineado con los procesos del negocio y con los
requerimientos de los usuarios.
El desarrollador puede agregar, modificar o eliminar los elementos que
considere necesario del modelo UML2 para cumplir con los requerimientos
de los usuarios. Puede agregar estereotipos del perfil independiente de la
plataforma, atributos, operaciones, clases y asociaciones entre las clases.
A partir del modelo UML 2 obtenido por la transformación se puede generar
automáticamente un modelo UML 2 específico de la plataforma o código
fuente en distintas tecnologías.
En la sección 4.2, se explica la transformación de BPMN 2 a UML 2.
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.
A partir del modelo obtenido en el punto anterior, se puede aplicar la segunda
transformación sobre este modelo que actúa como origen y que resulta en un
modelo UML2 con estereotipos dependientes de la plataforma Java EE. Los
141
resultados obtenidos con la definición y la aplicación de la transformación brinda
los siguientes beneficios:
Genera automáticamente un modelo específico de la plataforma JavaEE en
base a los elementos del modelo UML 2 generados por la primera
transformación.
Permite reducir la complejidad en el proceso de desarrollo de software al
permitir contar automáticamente con un modelo específico de la plataforma.
Se sigue un proceso por etapas donde se trabaja con niveles graduales de
abstracción. Esto posibilita disminuir la brecha entre los requerimientos, el
modelo de proceso del negocio, el modelo de diseño y la implementación.
Los elementos generados en el modelo destino pueden ser modificados
utilizando cualquier herramienta UML2 compatible con la implementación
UML2 de la plataforma Eclipse.
El desarrollador puede agregar o quitar anotaciones o modificar las
propiedades de las anotaciones para generar código fuente más detallado.
A partir del modelo UML 2 obtenido por la transformación se puede generar
automáticamente código fuente para la plataforma JavaEE.
En la sección 4.3, se explica la transformación de un modelo UML2 con perfil
independiente de la tecnología a un modelo UML2 con perfil Ejb3.1-JPA2.
Transformación del último modelo a código fuente java que compone los
elementos de la capa del negocio Java EE.
La transformación de UML 2 con estereotipos del perfil EJB 3.1-JPA 2 a código
fuente permite obtener a partir de un modelo UML 2 con perfiles, un prototipo de
componentes del negocio JavaEE que puede ser desplegado en un servidor de
aplicaciones. Los resultados obtenidos con la definición y la aplicación de la
transformación brinda los siguientes beneficios:
El desarrollador puede tomar el modelo ya refinado por las anteriores
transformaciones y agregar el detalle que necesario.
Reduce el esfuerzo requerido para el desarrollo de software al permitir
disponer rápidamente de componentes de la capa del negocio Java EE
funcionando.
Los componentes generados pueden exponer WebServices que permiten
probar su funcionamiento, interoperar e integrarse a los sistemas existentes
en la organización.
Los componentes generados pueden interactuar con los procesos que se
ejecutan en un sistema de gestión de procesos del negocio.
142
En la sección 4.4, se explica la transformación de un modelo UML2 con perfil
independiente de la tecnología a un modelo UML2 con perfil Ejb3.1-JPA2.
Método de trabajo para el desarrollo y validación de las transformaciones.
Se define un método de trabajo que permite en forma iterativa e incremental crear
versiones cada vez más refinadas de las transformaciones. Los resultados obtenidos
con la definición y la aplicación del método de trabajo ofrece los siguientes
beneficios:
El método permite la mejora continua y la evolución de las transformaciones
para lograr como producto cada vez mejores modelos destino. Los modelos
producto de las transformaciones se validan mediante casos de estudio que
permiten obtener resultados que prueban la efectividad de la solución
propuesta.
El método de trabajo propuesto se puede extender a otros proyectos de
transformaciones que tengan como origen un modelo del negocio BPMN 2.
Una etapa fundamental del método que se puede reutilizar en otros proyectos
de desarrollo de transformaciones es la validación.
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 la etapa de validación se trabaja sobre el supuesto que el
modelo o el código fuente destino de las transformaciones, se puede pensar
como una estimación del modelo o código fuente que podrían haber
elaborado ingenieros de software.
El método 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 la sección 1.3, se define la metodología de trabajo. En la sección 5.1, se muestra
la aplicación del método de trabajo.
6.1.1 Extensión de los resultados a otros proyectos:
Los resultados obtenidos se pueden extender a otros casos o proyectos porque se utilizan
estándares y herramientas open source. Las transformaciones definidas se pueden
almacenar en un repositorio de código fuente para gestionar el versionado y facilitar la
reutilización en nuevos proyectos. Si bien las transformaciones están pensadas para ser
aplicadas desde un modelo técnico BPMN 2, se puede utilizar la segunda y tercer
transformación en modelos UML 2 anotados con los perfiles propuestos.
El producto de las transformaciones puede utilizarse con herramientas o plataformas que
sean compatibles con los estándares utilizados. Los modelos generados en el destino
pueden ser modificados utilizando cualquier herramienta UML2 compatible con la
implementación UML2 de la plataforma Eclipse.
143
Los perfiles propuestos pueden incorporarse en la lista de perfiles o metamodelos de las
herramientas. El desarrollador puede agregar o quitar anotaciones o modificar las
propiedades de las anotaciones para generar código fuente más detallado.
6.1.2 Aporte que brindan los resultados a la ingeniería de software
El aporte a la ingeniería de software son transformaciones, perfiles y un método de trabajo.
La propuesta beneficia al desarrollo de software permitiendo aumentar la calidad y
disminuir errores de diseño. Permite acortar la brecha entre el proceso del negocio basado
en los requerimiento del usuario y los artefactos relacionados con el desarrollo del software.
Se demuestra que se puede hacer un desarrollo basado en procesos utilizando MDA que
permita obtener automáticamente modelos UML 2 y código fuente.
La propuesta impacta sobre la mejora de los niveles de calidad y productividad en el
desarrollo de software. Se trabaja sobre las transformaciones con la concepción de que es
una herramienta que se perfecciona continuamente con cada iteración. Los problemas en
los modelos o código fuente generados se pueden encontrar y eliminar con la corrección en
cada iteración de las transformaciones. Con el tiempo las transformaciones tienden a quedar
libre de defectos siempre bajo la perspectiva de: los criterios, normas, heurísticas y patrones
de diseño utilizadas por el grupo de desarrollo. Las transformaciones se pueden reutilizar en
nuevos proyectos de desarrollo de software.
Siguiendo el método de trabajo empleado para la mejora continua de las transformaciones
se puede disminuir con cada nueva versión los errores en el modelo destino generado.
Podemos pensar que el grupo de desarrollo trabaja con un repositorio de transformaciones
que evolucionan constantemente utilizando la metodología de trabajo propuesta. En cada
iteración no solo se mejoran los errores en las transformaciones también se agregan nuevas
relaciones para obtener modelos con mayor nivel de detalle. Esto contribuye a la mejora
continua de la calidad.
Con respecto a la mejora de la productividad la propuesta utiliza un método de trabajo,
perfiles y transformaciones QVT para mejorar permanentemente los tiempos en los que se
producen modelos y código fuente de calidad. Se puede lograr la misma funcionalidad
aplicando cada vez menor esfuerzo y generando componentes de código fiables.
En resumen los resultados obtenidos en esta tesis integran una propuesta cuyas
características se puede ver en la siguiente tabla:
Tabla 6.1 Resumen de Resultados Transformaciones MDA Se cubren niveles CIM, PIM, PSM y componentes del
negocio. Se definen las transformaciones MDA entre los
modelos.
Uso de Estándares
Lenguaje de modelado
estándares
Nivel CIM: Modelado de procesos del negocio: BPMN 2.0
Nivel PIM: UML 2 con perfil UML independiente de la
plataforma.
Nivel PSM: UML 2 con perfiles UML
144
Transformaciones
formalizadas
Se utiliza el estándar de la OMG. El lenguaje QVT-Relations.
Se utiliza la herramienta Acceleo que tiene una
implementación estándar del lenguaje MTL.
Metamodelos
estándares
Se utilizan metamodelos completos basados en estándares.
Alineamiento entre el
Negocio y los Sistemas
Informáticos
Se definen transformaciones desde el nivel CIM
Integración con BPMS Se emplea el lenguaje y metamodelo estándar BPMN 2 que
nos permite utilizar un modelo de procesos ejecutable en un
sistema de gestión de procesos de negocio
6.2 Principales Aportes y Publicaciones
Las contribuciones principales son:
Lograr el objetivo de mantener la consistencia entre los modelos de procesos
técnicos y los componentes del negocio Java EE, para, de esta manera, permitir
mejorar la eficiencia y eficacia de la organización en la implementación total o
parcial de procesos automatizados. De esta forma es posible mejorar la
productividad en el desarrollo y disminuir errores de diseño.
Un método para que mediante transformaciones de un modelo BPMN 2 ejecutable
se obtenga código fuente desplegable en un servidor Java EE. Las transformaciones
se pueden reutilizar en nuevos proyectos de desarrollo de software.
A partir de la información contenida en un diagrama BPMN 2.0 ejecutable, obtener
una arquitectura lógica de una aplicación Enterprise Java EE.
Un método para obtener en forma semiautomática modelos independientes de la
plataforma (PIM) y modelos especifico de la plataforma (PSM).
La definición de un perfil independiente de la tecnología cuyas anotaciones se
pueden aplicar a modelos UML 2 para generar modelos con mayor nivel de detalle
en base a transformaciones QVT.
La definición de un perfil para la plataforma Ejb 3.1-Web Services (JAX-WS) para
facilitar la transformación de un modelo UML 2 a la tecnología JavaEE.
La propuesta beneficia al desarrollo de software permitiendo aumentar la calidad al
disminuir la brecha entre el proceso del negocio basado en los requerimiento del
usuario y los artefactos relacionados con el desarrollo del software. Al basarse en
UML2 estándar, el desarrollador puede tomar los modelos UML 2 de las
transformaciones y agregar los detalles necesarios que permitan cumplir con los
requerimiento del análisis Orientado a Objetos.
145
Al utilizar como modelo origen una instancia del metamodelo estándar BPMN 2,
este modelo sirve de entrada para un BPMS y para la herramienta MDA
desarrollada en este trabajo, permitiendo la interoperación entre ambas por medio de
tipos de tareas BPMN 2 como ServiceTask.
La solución propuesta es orientada a estándares abiertos. Se utilizan estándares en
cada parte de la solución como: QVT, BPMN 2, UML2, XMI, Web Services SOAP,
etc.. El uso de estándares abiertos permite el intercambio de los modelos generados
entre aplicaciones libremente y sin limitaciones legales o de pagos de derechos.
La propuesta se puede incluir en cualquiera de las plataformas BPMS que trabajen
con el estándar BPMN 2 e interactuar con los componentes Java EE generados
utilizando WebServices.
Durante los años 2011 y 2012 se generaron y publicaron artículos en los congresos que se
mencionan a continuación:
Martinez C.A. , Zorzan, F. , Riesco D. “Transformación de modelos ejecutables
bpmn 2 a la tecnología enterprise java beans 3.1-java api persistence 2”. Jornadas de
Ingeniería CODINOA 2011.
Debnath, N. , Martinez C.A. , Zorzan, F. , Riesco D., Montejano, G.
“Transformation of business process models BPMN 2.0 into components of the
Java business platform”. Industrial Informatics (INDIN), 2012 10th IEEE
International Conference.
En base al material publicado en relación a la tesis, durante el año 2013 se trabajó como
consultante en la tesis para obtener el título de grado de Ingeniero Informático de Sandy
Soler Martínez de la Universidad de Holguín- República de Cuba. El título de la tesis ya
aprobada es:
Propuesta de reglas para la Transformación del Modelo Independiente de la
Computación al Modelo Independiente de la Plataforma.
6.3 Líneas de Trabajo Futuras
El resultado de este trabajo de tesis puede ser continuado principalmente en línea de
transformaciones de modelos siguiendo un enfoque MDA. Se pueden refinar los
componentes de la propuesta y agregar nuevos elementos siempre trabajando con
estándares y software de código abierto. Se pueden refinar las transformaciones y perfiles
propuestos siguiendo el método de trabajo definido en el capítulo 1.
Muchas de las características que se han ido agregando en cada versión de este trabajo han
surgido de los caso de estudio con los que se ha trabajado. Se pueden crear nuevos casos de
estudio que sigan el método planteado en el capítulo 1 para mejorar las transformaciones y
146
perfiles planteados. Se pueden agregar nuevas transformaciones relacionadas con los
elementos del metamodelo BPMN 2 como timer y reglas del negocio.
El Interaction Flow Modeling Language (IFML) [61] es un estándar de la OMG, centrado
en el modelado independiente de la plataforma de interfaces gráficas de usuarios. La
generación de interfaces de usuarios utilizando la herramienta Acceleo a partir de un
modelo IFML es algo que se puede implementar y relacionar con las transformaciones
propuestas. Nos parece que este podría ser un aporte muy importante a las transformaciones
ya planteadas en este trabajo de tesis. De esta forma, quedarían cubiertos casi todos los
aspectos de la arquitectura de una aplicación empresarial.
6.4 Conclusiones finales
Las organizaciones de la actualidad están en permanente cambio siendo una necesidad tener
automatizados total o parcialmente sus procesos de negocio. 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. 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 este trabajo de tesis se ha generado una propuesta MDA donde se han utilizado en todas
sus etapas: estándares, herramientas y componentes de código abierto. El objetivo ha sido
seguir un método que permita a partir de un modelo CIM basado en el estándar BPMN 2
definir transformaciones con el estándar QVT para generar modelos UML 2 y en base a
estos modelos dar la posibilidad de obtener código fuente Java con transformaciones MTL.
Siguiendo un método de trabajo se han ido generando versiones cada vez más refinadas de
las transformaciones. Estas versiones han ido evolucionando a partir de los problemas y
requerimientos surgidos a partir de la validación y pruebas con los casos de estudio reales y
de laboratorio diseñados.
Se diseñan y se utilizan en las transformaciones perfiles: independiente de la plataforma,
Ejb 3.1-Web Services y JPA 2. Para realizar las transformaciones se ha utilizado la
herramienta Medini QVT que permite la ejecución de transformaciones QVT expresadas
con la sintaxis textual del lenguaje Relations. Para transformación de modelos UML 2 con
perfiles a los componentes Java EE se utiliza la herramienta Acceleo que utiliza el lenguaje
estándar MTL.
La propuesta beneficia al desarrollo de software permitiendo aumentar la calidad y
disminuir errores de diseño. Al basarse en UML 2 estándar el desarrollador puede tomar los
modelos UML de las transformaciones y agregar los detalles necesarios que permitan
cumplir con los requerimientos de los usuarios y del análisis y diseño Orientado a Objetos.
Al utilizar como modelo origen una instancia del metamodelo estándar BPMN 2. Este
modelo sirve de entrada para un BPMS (Business Process Management Suite) y para
nuestra herramienta MDA permitiendo la interoperación entre ambas.
147
En resumen, este trabajo de tesis de maestría presenta una propuesta para que, mediante
transformaciones de un modelo BPMN 2 ejecutables 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 ejecutable se puede obtener una arquitectura lógica de una aplicación
Enterprise Java EE. La herramienta generada cumple 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. Para validar la propuesta se han utilizado casos
de estudio de laboratorio y reales que han permitido la mejora continua de las
transformaciones propuestas.
148
7. Anexos
En esta sección se muestran los anexos de los que se compone la Tesis de Maestria. El
primer anexo presenta el metamodelo BPMN 2. En el segundo anexo se describen los
elementos principales de la notación BPMN 2. El tercer anexo presenta el metamodelo
UML 2. Los siguientes tres anexos presentan el código fuente de las transformaciones
desarrolladas.
7.1 Anexo1. Metamodelo BPMN 2.0
En la sección 2.4 del capítulo 2 se trató el estándar BPMN 2 desde el punto de vista del
BPMN framework [20] y del modelado. En este anexo, se detallan los componentes del
metamodelo BPMN 2 [1] utilizados en el desarrollo de la presente tesis.
7.1.1 BPMN Core Structure
La estructura técnica de BPMN 2 se basa en el concepto de capas extensibles, cada capa se
basa y extiende a las capas inferiores. El núcleo en esta serie de capas incluye los elementos
de BPMN necesarios para el modelado de procesos y colaboraciones utilizados en las
transformaciones de éste trabajo.
En base al núcleo se estructuran las capas que se utilizan para describir los elementos de la
especificación. El modelo de esquema XML [55] se utiliza para formalizar la definición de
los elementos de forma de evitar ambigüedades y facilitar el intercambio de modelos. El
núcleo de BPMN consiste de cuatro paquetes:
Fundación (Foundation): Las construcciones fundamentales para el modelado de
diagramas en BPMN.
Insfraestructura (Infrastructure): El paquete de infraestructura se compone de dos
elementos que son relevantes para la importación y exportación.
Servicio (Service): Las construcciones fundamentales para el modelado de los
servicios y las interfaces.
Comunes o frecuentes (Common): Aquellas clases que son comunes a las capas de
Proceso, Coreografía y Colaboración.
En la figura 7.1, se muestra el diagrama de clases de la organización de los elementos del
núcleo de BPMN 2.
149
Figura 7.1 Elementos del núcleo de BPMN 2.0
En las siguientes subsecciones se describen las construcciones utilizadas en esta tesis como
elementos del metamodelo origen para su transformación en elementos UML 2.
7.1.1.1 Infraestructura (Infrastructure)
El paquete Infrastructure contiene a los elementos: Definitions e Import. El elemento
Definitions contiene a todos los elementos de BPMN. Define el alcance de visibilidad y el
espacio de nombres para todos los elementos que contiene. El intercambio de archivos
BPMN siempre se hace a través de uno o más elementos Definitions. En la figura 7.2, se
observa el diagrama de clases del elemento Definitions.
150
Figura 7.2 Elementos del núcleo de BPMN 2.0
El elemento Definitions hereda los atributos y las asociaciones de BaseElement. El
elemento BaseElement se explica en la sección 7.1.1.2. En la Tabla 7.1, se muestran los
atributos utilizados en este trabajo para el elemento Definitions.
Tabla 7.1 Atributos para elemento Definiciones (Definitions)
Nombre de Atributo Descripción
Name: String El nombre del elemento definitions
targetNamespace:
string
Identifica el espacio de nombres asociado con Definitions y la
convención establecida por el esquema XML.
expressionLanguage:
string [0..1]
Identifica mediante el formato URI el lenguaje de expresión
formal utilizado. Por defecto “http://www.w3.org/1999/XPath”.
typeLanguage: string
[0..1]
Identifica el tipo de sistema usado por los elementos de
Definitions. Por defecto http://www.w3.org/2001/XMLSchema.
Debe estar en formato URI.
151
En la figura 7.3, se muestra un ejemplo de un archivo que contiene una declaración de
Definitions. Arriba de la figura se observa una vista del elemento en formato gráfico
interpretado por el “Reflective Ecore Model Editor” en la parte de abajo el ejemplo en
XML utilizando el estándar xmi (XML Metadata Interchange Specification) [21]. En
posteriores ejemplos se utiliza la misma forma.1.
Figura 7.3 Ejemplo de Definitions
La clase Import se utiliza para hacer referencia a elementos externos, ya sea elementos
BPMN contenidos en otros Definitions o elementos no relacionados con BPMN. Las
importaciones deben ser definidas explícitamente.
7.1.1.2 Fundación (Foundation)
El paquete Foundation contiene las clases que comparten otros paquetes en el núcleo. En la
figura 7.4, se muestra el diagrama de clases.
152
Figura 7.4 Clases del paquete Foundations
Dentro de Foundations podemos destacar dos elementos importantes que se utilizan en el
modelado de este trabajo:
Elemento Raiz (Root Element)
Es la clase súper abstracta para los elementos BPMN que están contenidos dentro
del elemento Definitions. Cuando los elementos están contenidos dentro de
Definitions tienen su propio ciclo de vida y no se eliminan sí se eliminan otros
elementos. Ejemplos de RootElements pueden ser Collaboration y Process.
RootElemnts puede estar referenciado por otros elementos. Algunos RootElements
pueden estar contenidos dentro de otros elementos en lugar del elemento
Definitions. El elemento RootElement hereda los atributos y las asociaciones de
BaseElement.
Elemento Base (Base Element)
BaseElement es la súper clase abstracta para la mayoría de los elementos de BPMN.
Proporciona los atributos identificador y documentación. El atributo id
(identificador) permite identificar en forma única un elemento BPMN. El atributo
documentación (documentation) es utilizado con fines de documentación para
agregar anotaciones sobre los elementos BPMN 2.
153
7.1.2 Colaboración (Collaboration)
El paquete Collaboration contiene las clases para el modelado de colaboraciones. Una
colaboración permite modelar las interacciones entre dos o más entidades del negocio o
roles del negocio, que se representan como participantes dentro de una Piscina (Pool). Las
interacciones se representan mediante mensajes que intercambian los participantes
pertenecientes a la colaboración. En la figura 7.5, se muestra el diagrama de clases del
paquete Collaboration.
Figura 7.5 Clases del paquete Collaboration
La clase Collaboration hereda los atributos y las asociaciones del elemento BaseElement a
través de su relación con RootElement. La tabla 7.2, muestra los atributos utilizados en este
trabajo para el modelado de colaboraciones.
Tabla 7.2 Atributos Principales de Collaboration
Nombre de
Atributo
Descripción
Name: String El nombre del elemento Collaboration
participants: Participant [0..*]
Proporciona la lista de participantes que se utilizan en la
colaboración. Los participantes se muestran como pools en una
colaboración
messageFlow:
Message Flow
[0..*]
Proporciona la lista de mensajes de flujo que son usados en una
colaboración. El elemento Message Flows (flujo de mensaje) se
muestra como una línea discontinua en una colaboración.
Un elemento Pool puede estar vacío o puede mostrar un proceso interior. Un Pool es la
representación gráfica de un participante en una colaboración. Un participante puede ser
una entidad o rol del negocio como: una empresa, comprador, vendedor. Un Pool puede o
no hacer referencia a un Proceso. Es decir, que un Pool puede no contener un procesos y en
ese caso es una “ Caja Negra”, representado gráficamente mediante un Pool vacío.
154
Comúnmente un participante es responsable de la ejecución de un Proceso encerrado en un
Pool, sin embargo, un Pool puede ser definido sin un proceso. La figura 7.6, muestra la
relación de los elementos participantes y de mensajes de flujo con una colaboración
contenida en un elemento Definitions.
Figura 7.6 Clases del paquete Collaboration
Flujo de Mensaje (Message Flow)
Un flujo de mensajes modela el flujo de mensajes entre dos participantes.
Un flujo de mensajes debe conectar dos Pool separados. Se conectan en el límite del Pool.
No pueden conectar a elementos dentro del Pool.
En la figura 7.5, se muestra la relación entre un Message Flow y la clase Collaboration. La
tabla 7.3 muestra los atributos utilizados en este trabajo para el modelado de mensajes de
flujo.
Tabla 7.3 Atributos Principales de Message Flow
Nombre de Atributo Descripción
name: string El nombre del elemento Message Flow.
sourceRef:
InteractionNode
El elemento desde el cual se conecta el flujo de mensaje.
targetRef:
InteractionNode
El elemento a donde se conecta el flujo de mensaje.
Nodo de Interacción (InteractionNode)
El elemento InteractionNode se utiliza para representar mediante un elemento la fuente y el
destino de un mensaje de flujo. Sólo los Pools, participantes, actividades y eventos pueden
conectarse a un flujo de mensajes.
155
7.1.3 Proceso (Process)
Un elemento Process representa un flujo de actividades que ocurre en una organización con
el objetivo de realizar un trabajo. Un proceso BPMN está formado por un conjunto de
elementos de flujo como: actividades, eventos, pasarelas y flujos de secuencia que definen
la semántica de ejecución. Se utilizan los diagramas de Colaboración y coreografía para
modelar la interacción entre los procesos.
El paquete Process se compone por las clases que se utilizan para modelar el flujo de
Actividades como: Eventos (Events) y Compuertas (Gateways), y los elementos
relacionados con la secuencia de objetos dentro de un proceso. La definición de un proceso
se hace dentro del elemento Definitions. Un proceso es un elemento reutilizable y puede ser
importado y utilizado en otros elementos Definitions. En la figura 7.7, se observa el
diagrama de clases que muestra las relaciones del elemento Proceso (Process).
Figura 7.7 Clases del paquete Process
La figura 7.8, muestra los detalles de los atributos y las asociaciones de un modelo de
proceso.
156
Figura 7.8 Asociaciones y atributos de un modelo de proceso
La tabla 7.4 muestra los atributos utilizados en este trabajo para el modelado de procesos.
Tabla 7.4 Atributos Principales del elemento Process
Nombre de
Atributo
Descripción
processType:
ProcessType = none
{ None | Private |
Public }
El atributo processType proporciona información sobre el nivel de
abstracción de modelado de un proceso. Un proceso público sólo
muestra los elementos de flujo que son relevantes para los
consumidores externos. Detalles internos no se modelan. Estos
procesos son públicamente visibles y se puede utilizar dentro de una
colaboración. Un proceso privado es interno a una organización. Por
defecto, el atributo processType es "none", es decir, sin definir.
isExecutable:
boolean [0..1]
Un valor booleano opcional que especifica si el proceso es
ejecutable. Un proceso ejecutable es un proceso privado que ha sido
modelado con el fin de ser ejecutado. Un proceso no ejecutable es un
proceso privado que ha sido modelado con el fin de documentar el
comportamiento del proceso a un nivel definido por el modelador de
detalle. Por lo tanto, la información necesaria para la ejecución, tales
como expresiones de condiciones formales no están normalmente
incluidas en un proceso no ejecutable.
7.1.3.1 Tipos de procesos del Negocio
Hay tres tipos básicos de procesos BPMN:
Privados no ejecutables(internos)
157
Privados ejecutables (internos)
Procesos públicos
Un proceso no ejecutable es un proceso privado que ha sido modelado con el fin de
documentar el comportamiento del proceso. Un proceso ejecutable es un proceso que se ha
modelado con el propósito de ser ejecutado de acuerdo a la semántica definida por la
especificación de BPMN 2.
Un proceso público representa las interacciones entre un proceso del negocio privado y
otros Procesos o Participantes. Sólo aquellas actividades que se utilizan para comunicarse
con otro/s participante/s, más el orden de estas actividades, se incluyen en el proceso
público. Las demás actividades internas del proceso del negocio privado no se muestran en
el proceso público.
En la figura 7.9, se muestra un ejemplo de un proceso ejecutable en formato gráfico y xmi.
Figura 7.9 Ejemplo de elemento Process de tipo ejecutable
7.1.4 Actividades (Activities)
Una actividad es un trabajo que se realiza dentro de un proceso de negocio. Una actividad
puede ser atómica o no atómica (compuesta). Los tipos de actividades que son parte de un
proceso son: Task, Sub-Process y call Activity. Las actividades representan puntos en un
flujo de proceso en donde se realiza el trabajo.
La clase de actividad es un elemento abstracto que es una subclase de FlowElement como
se muestra en la figura 7.7. Las subclases de Activity especifican semántica adicionales
más allá de la definida por la clase genérica Activity. La clase Activity es la clase súper
abstracta para todos los tipos de actividad concretos.
7.1.4.1 Tareas (Tasks)
Una tarea es una actividad atómica dentro de un flujo de proceso. Una tarea se utiliza
cuando el trabajo en el proceso no se puede dividir a un mayor nivel de detalle. La figura
7.10, muestra el diagrama de clases para el elemento Task.
158
Figura 7.10 Diagrama de clases para el elemento Task.
Hay diferentes tipos de tareas en BPMN para representar los distintos tipos de
comportamiento que las tareas puedan representar.
Tareas de Servicio (Service Task)
Una tarea de servicio es una tarea que utiliza algún tipo de servicio, lo que podría ser un
servicio Web o una aplicación automatizada.1. El elemento Service Task hereda los
atributos y asociaciones de modelos de la clase Activity. Además, las siguientes
restricciones se introducen cuando la función de servicio hace referencia a una operación:
la tarea de servicio tiene exactamente un inputSet y no más de un outputSet .
Tiene una entrada de datos(Data Input) con un ItemDefinition. Si la operación define
mensajes de salida, el Service Task tiene una salida de datos(Data Output) única que tiene
una ItemDefinition . La figura 7.11, muestra el diagrama de clases para el elemento Service
Task.
159
Figura 7.11 Diagrama de clases para el elemento Service Task
La tabla 7.5, muestra los atributos utilizados en este trabajo para el modelado del elemento
Service Task.
Tabla 7.5 Atributos Principales del elemento Service Task
Nombre de Atributo Descripción
implementation:
string =
##webService
Con este atributo se define la tecnología que se utiliza para enviar y
recibir los mensajes. Los valores válidos pueden ser "# #
unspecified" o "# # WebService"; por defecto se utiliza Web
Services o un URI que identifica a otra tecnología o protocolo.
operationRef:
Operation [0..1]
Este atributo especifica la operación que es invocada por el Service
Task.
La figura 7.12 muestra un ejemplo del elemento Service Task.
Figura 7.12 Ejemplo de elemento Service Task.
Tarea de Script (Script Task)
Un elemento Script Task se ejecuta mediante un motor de procesos de negocio. El
modelador o implementador define un script en un lenguaje que el motor de procesos del
negocio puede interpretar. Cuando la tarea está lista para empezar, el motor ejecuta el
script. Cuando el script está terminado, la tarea también será completada.1. El elemento
Script Task hereda los atributos y asociaciones del modelo de Activity. La Tabla 7.6,
muestra los atributos utilizado en el modelado del elemento Script Task.
160
Tabla 7.6 Atributos Principales del elemento Script Task
Nombre de
Atributo
Descripción
scriptFormat: string
[0..1]
Define el formato del Script
script: string [0..1] El modelador puede incluir un script que se puede ejecutar cuando
la tarea se lleva a cabo.
7.1.5 Modelado de Datos
El modelado de procesos necesita la utilización de elementos que permitan representar
operaciones sobre una estructura de datos. Este requerimiento se cumple en BPMN a través
de la definición de elementos como DataStore.
BPMN no contempla un modelo integrado para la descripción de una estructura de datos o
un lenguaje de expresiones para consultar esos datos. Permite la utilización de múltiples
estructuras de datos y lenguajes de expresión dentro del mismo modelo. Define a XML-
Schema [54] y XPath (XML Path Language) [56] como su estructura de datos y lenguaje de
expresión por defecto, pero el estándar da la posibilidad de utilizar lenguajes distintos.
7.1.5.1 Almacén de Datos (Data Stores)
Un elemento DataStore proporciona un mecanismo para que las actividades puedan
recuperar o actualizar la información almacenada que persiste más allá del alcance de un
proceso. El DataStore se puede visualizar, a través de una referencia mediante el elemento
Data Store Reference, en uno o más lugares en el proceso.
Cuando los flujos de datos entran o salen de un elemento DataStoreReference significa que
entran y salen de un DataStore. La figura 7.13, muestra el diagrama de clases para el
elemento DataStore.
161
Figura 7.13 Diagrama de clases para el elemento Data Store
El elemento DataStore hereda los atributos y asociaciones de FlowElement a través de su
relación con RootElement y ItemAwareElement. El elemento DataStoreReference hereda
los atributos y asociaciones de FlowElement y ItemAwareElement. En la figura 7.14, se
muestra un ejemplo del elemento DataStore.
Figura 7.14 Ejemplo de DataStore
7.1.6 Carril (Lane)
El elemento Lane representa a una entidad responsable de un proceso. Un Lane es una sub-
partición dentro de un proceso comúnmente dentro de un Pool. Los elementos Lane son
utilizados para organizar y categorizar elementos dentro de un Pool.
Un elemento LaneSet se utiliza como contenedor de una colección de Lanes. Un proceso
puede contener uno o más LaneSet. A su vez un elemento LaneSet está compuesto por uno
o más Lane. El elemento LaneSet hereda los atributos y las asociaciones de modelo de
BaseElement. La figura 7.15, muestra el diagrama de clases para el elemento Lane.
162
Figura 7.15 Diagrama de clases para el elemento Lane
En la Tabla 7.7, se observan los atributos utilizados en el modelado del elemento LaneSet.
Tabla 7.7 Atributos Principales del elemento LaneSet
Nombre de
Atributo
Descripción
name: sting [0..1] El nombre del LaneSet.
process: Process El proceso que tiene relacionado el elemento LaneSet.
lanes: Lane [0..*] Uno o más elementos del Lane, que definen una partición específica
en el LaneSet.
parentLane: Lane
[0..1]
La referencia a un elemento Lane que es el padre de este LaneSet.
Un elemento Lane define una partición específica en un LaneSet. Los Lanes dentro de un
LaneSet deben definir elementos del mismo tipo. El elemento Lane hereda los atributos y
las asociaciones de modelo de BaseElement. En la Tabla 7.8, se muestran los atributos
utilizado en el modelado del elemento Lane.
Tabla 7.8 Atributos Principales del elemento Lane
Nombre de Atributo Descripción
name: sting [0..1] El nombre del elemento Lane.
partitionElement:
BaseElement [0..1]
Una referencia a un elemento BaseElement que especifica el valor
y el tipo de la partición. Utilizando este elemento de partición un
herramienta compatible con el estándar BPMN puede determinar
163
los elementos de flujo que tienen que ser particionados en este
Lane.
partitionElementRef:
BaseElement [0..1]
Una referencia a un elemento BaseElement que especifica el valor
y el tipo de la partición. Utilizando este elemento de partición un
herramienta compatible con el estándar BPMN puede determinar
los elementos de flujo que tienen que ser particionados en este
Lane.
childLaneSet:
LaneSet [0..1]
Una referencia a un elemento LaneSet para Lanes embedidos.
flowNodeRefs:
FlowNode [0..*]
La lista de los elementos FlowNodes particionados dentro de un
Lane de acuerdo a partitionElment definido como parte del
elemento Lane.
En la figura 7.16, se muestra un ejemplo de un proceso que tiene un elemento LaneSet
compuesto por dos Lane. El elemento con nombre Lane1 hace referencia a varios
elementos por medio de su atributo flowNodeRef.
Figura 7.16 Ejemplo de LaneSet y Lane
164
7.2 Anexo 2. Metamodelo UML 2
El metamodelo UML 2.0 forma parte del nivel M2 dentro de la jerarquía de cuatro niveles
Meta Object Facility (MOF) [4]. El nivel superior es el del meta-metamodelo MOF. UML
es una instancia de MOF y es más específico que este. Es necesario destacar que UML y
MOF dependen de un núcleo compartido que es reusado por ambos.
Teniendo en cuenta el objetivo planteado en la presente tesis de transformar un modelo
BPMN 2 a UML 2 [5] y de UML 2 a UML 2 con estereotipos del perfil EJB 3.1-JPA 2. Es
necesario explicar los elementos del metamodelo UML 2. Para cumplir con este objetivo se
describen en las siguientes secciones los elementos esenciales para el desarrollo de las
transformaciones propuestas.
7.2.1 Especificación UML 2
El Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling
Language) es una especificación de la OMG que se ha convertido en un estándar de facto
para modelar sistemas de software. La especificación actual es la de UML 2.4.1 [5], está se
divide en dos documentos complementarios: Infrastructure y Superstructure.
UML 2 Infrastructure [62] define los elementos principales que sirven de base para la
construcción del lenguaje UML 2. Contiene los elementos básicos del metamodelo,
proporcionando además mecanismos de extensión del lenguaje. UML 2 está alineado con
MOF [4], el paquete Core es compartido por UML y por MOF. Es decir, el núcleo de MOF
se define utilizando la infraestructura de UML y a la vez UML se define utilizando MOF.
UML 2 Superstructure [63] complementa a UML 2 Infrastructure. Define construcciones
para el modelado de aplicaciones a nivel del usuario divididas en una parte estructural y
otra del comportamiento, siendo una especificación que reúsa los elementos de UML 2
Infrastructure.
Estos documentos constituyen una completa especificación para el lenguaje de modelado
cuya actual revisión es la 2.4.1.
7.2.2 Infraestructura (Infrastructure)
La Infraestructura de UML se especifica mediante la InfrastructureLibrary. Está define un
núcleo básico que se puede reutilizar para definir una diversidad de metamodelos, como
MOF y UML. El intercambio de modelos está soportado debido a su alineación con UML,
MOF y XMI [21].
La Infraestructura permite extender UML con el uso de perfiles y crear nuevos lenguajes
basados en el mismo metalenguaje como UML. La infraestructura (Infrastructure) está
compuesta por los paquetes: InfrastructureLibrary y PrimitiveTypes. En la figura 7.17, se
representan los paquetes InfrastructureLibrary y PrimitiveTypes.
165
Figura 7.17 Paquetes de Infrastructure
El paquete PrimitiveTypes posee tipos predefinidos primitivos que se usan frecuentemente
en el metamodelado. Define un conjunto de tipos básicos usados para definir la sintaxis de
los metamodelos. Hay cuatro tipos básicos: Integer, Boolean, String, UnlimitedNatural.
InfrastructureLibrary está formado por los paquetes Core y profiles. Es la base de varios
metamodelos incluyendo a MOF y UML. Dentro del paquete InfrastructureLibrary el
paquete Core es un metamodelo completo; diseñado para conseguir que metamodelos como
UML y MOF dependan de un núcleo común y puedan reutilizar los elementos ya definidos;
importando o especializando sus clases.
En la figura 7.18, se observa como el paquete Core de la InfrastructureLibrary es reusado
por los metaniveles M2 y M3 dentro de las cuatro capas de la arquitectura MOF de la
OMG; perteneciendo el metamodelo MOF y UML respectivamente a cada nivel. Teniendo
en cuenta los objetivos de MOF y de UML, los elementos de la InfrastructureLibrary son
reusados de distinta forma.2. MOF utiliza los elementos de la InfrastructureLibrary sin
modificarlos mientras que UML les agrega características adicionales.
166
Figura 7.18 Paquete Core y su relación con MOF y UML
Como se muestra en la figura 7.19, Core está compuesto por los paquetes: Abstractions,
Basic, and Constructs.
Figura 7.19 Paquetes de InfrastructureLibrary
Abstractions consiste de varios paquetes con el objetivo de proveer un conjunto de clases
reusables que puedan ser especializadas cuando se definen nuevos metamodelos.
Concretamente define los elementos básicos y las asociaciones usadas en los
metalenguajes, por ejemplo: Element, Classifier, Comment, Generalization y otros.
Constructs define varias construcciones, como: package merge, expressions, constraint y
otros. Las metaclases en Constructs comúnmente no son abstractas y tienen que ver con el
modelado Orientado a Objetos. Es el paquete que es utilizado por el núcleo de UML.
Basic es un lenguaje de modelado reducido a partir del cual se construyen lenguajes
complejos como MOF. En este paquete se definen elementos como: diagrama de clases,
paquete, tipo de datos, propiedades y operaciones.
El paquete Profiles depende del paquete Core, y define los mecanismos que se utilizan para
adaptar metamodelos existentes hacia plataformas específicas, como CORBA [64], EJB 3.1
[6], o dominios como el de modelado de procesos.
167
7.2.2.1 Paquete Basic del Core
El paquete Basic pertenece al paquete Core dentro del InfrastructureLibrary como se
muestra en la figura 7.19. Está compuesto por un conjunto mínimo de clases que pueden ser
reusadas por lenguajes pertenecientes a distintas capas de la arquitectura MOF, como se
muestra en la figura 7.18.
Basic importa elementos del paquete PrimitiveTypes y posee elementos derivados de
metaclases compartidos. Estos son definidos en los paquetes contenidos en el paquete
Abstractions.
En este trabajo del paquete Basic se explican los elementos Classes Diagram y Packages
que son los que se utilizan en la presente tesis. Estos elementos son luego reusados por el
paquete Constructs el cual reúsa UML especializando algunos elementos.
Diagrama de Clases (Classes Diagram)
El diagrama de clases define los elementos utilizados para el modelado basado en clases.
Como se observa en la figura 7.20, una clase está compuesta por propiedades y
operaciones. Las propiedades representan los atributos de una clase. Una operación es parte
de una clase y puede ser invocada en el contexto de los objetos que son instancia de estas
clases. Una operación puede estar compuesta por parámetros.
La semántica del modelo de clases tiene en cuenta las siguientes reglas:
Un elemento Clase (Class) es un tipo que tiene objetos como sus instancias.
Una clase puede participar en jerarquías de herencia.2.
Cuando una clase es abstracta no puede tener instancias directamente.
Una instancia de una clase concreta también es instancia indirecta de su superclase.
Un objeto puede ejecutar las operaciones de su clase y de sus superclases.
Una clase no puede acceder a características privadas de otra clase, o a
características protegidas sobre una clase que no es su supertipo.
168
Figura 7.20 Elementos del Diagrama de Clases del Package Basic tomado de [17]
Diagrama de Paquetes (Packages Diagram)
El diagrama de paquetes define los elementos relacionados con los paquetes y sus
contenidos. Un paquete (Package) es un contenedor que permite agrupar a tipos y otros
paquetes con el objetivo de entender y manejar mejor un modelo. Un paquete no puede
contenerse así mismo. Se puede especificar un identificador único de recursos para
identificar en forma única un paquete. En la figura 7.21, se puede observar a Package y sus
artefactos relacionados.
Figura 7.21 Elementos del Diagrama de Paquetes tomado de [17]
7.2.2.2 Paquete Constructs del Core
El paquete Constructs pertenece al paquete Core dentro del InfrastructureLibrary como se
muestra en la figura 7.19. Constructs depende de los paquetes de basic y de Abstractions;
también importa elementos del paquete PrimitiveTypes. En esta sección se describen los
elementos principales que son utilizados por el Kernel de UML y en las transformaciones
definidas en este trabajo. El paquete Constructs toma el diagrama de clases y el diagrama
169
de paquetes definido en el paquete basic y le agrega nuevas características que luego son
utilizadas por el núcleo de UML.
Diagrama de Clases (Classes Diagram)
El diagrama de clases define los elementos asociaciones, clases, propiedades y operaciones.
Crea nuevos elementos y agrega y redefine características de los elementos que toma
especialmente del paquete Basic. A continuación se describen los elementos más
importantes en el contexto de este trabajo.
Clase (Class)
Una clase define un conjunto de objetos que comparten la misma especificación
características, restricciones y semántica.2. Para definir este elemento en el paquete
Constructs se fusionan las características del elemento Class del paquete Basic con el
paquete Classifier proveniente del mismo Constructs. Classifier es una clase abstracta que
se refiere a una clasificación de instancias. Constructs define a Classifier en base a los
paquetes Basic y Abstractions y luego lo especializa agregando atributos adicionales.
En UML todos los elementos relacionados con el modelado que pueden tener instancias se
llaman clasificadores. Por ejemplo, las clases, tipos de datos como String o interfaz son
clasificadores.
Un elemento Class es un tipo de clasificador cuyas características son atributos y
operaciones. Los atributos de una clase son representadas por las instancias del elemento
Property que es parte de la clase.
En la figura 7.22, se muestra como el elemento Class hereda características del elemento
Classifier y está compuesto por propiedades y operaciones.
Figura 7.22 Elemento Class y sus relaciones tomado de [61]
Semántica
Una clase clasifica los objetos que están caracterizados por su estructura y comportamiento.
La estructura se define por medio de sus atributos y el comportamiento por sus operaciones.
170
Los atributos deben contener valores teniendo en cuenta sus características como su tipo y
multiplicidad. Al ser instanciado un objeto un atributo debe tener un valor inicial por
defecto o predeterminado sino tiene que ser evaluado para establecer un valor.
Las operaciones tienen parámetros que deben ser completados cuando son invocados por un
objeto. Invocaciones de una operación pueden también causar la creación y la eliminación
de objetos. Cuando una operación es llamada puede producir el cambio en el estado de un
objeto, es decir el valor de sus atributos puede cambiar. También puede causar cambios en
los atributos de los objetos relacionados con el objeto que invoca la operación, a los objetos
navegables desde sus parámetros, o con otros objetos en el ámbito de la ejecución de la
operación. También a partir de la invocación de una operación se puede obtener un
resultado si este ha sido definido.
Niveles de visibilidad
El paquete Visibilities es un subpaquete del paquete Abstractions que pertenece a la
Infraestructure. En este se definen los elementos que permiten especificar la visibilidad en
los elementos de un modelo UML.
La Visibilidad se utiliza en atributos y operaciones. Sirve para el encapsulamiento, es decir
ocultar los detalles de implementación del clasificador y sólo exponer aquellas
características necesarias para llevar a cabo sus responsabilidades. La visibilidad puede ser
de los siguientes tipos:
public (+): El elemento es visible o puede ser accedido por cualquier clasificador
externo que puede utilizar los característica.2.
protected (#): El elemento es visible o puede ser accedido por el propio clasificador
y sus descendientes.
private (-): El elemento es visible o puede ser accedido sólo por el propio
clasificador.
package (~): El elemento es visible o puede ser accedido sólo por los clasificadores
declarados en el mismo paquete.
Multiplicidad
En el caso de los atributos, la Multiplicidad indica el número de valores simultáneos que
pueden existir para cada instancia de la clase.
La opción por defecto es un solo valor (Multiplicidad = 1). En otro caso, se indica
señalando entre corchetes el número mínimo (lower) y máximo (upper) de valores posibles.
La notación que establece el estándar para definir la multiplicidad es la siguiente:
`[´[<mínimo> ‘..’] <máximo> `]´ [ ‘{´<orden> [‘,‘<unicidad>]’}’]
171
Donde:
mínimo: es un valor entero.
máximo: es un asterisco (*) o un valor entero.
orden: puede ser { ‘ordered’ | ‘unordered’ }.
unicidad: puede ser { ‘unique’ | ‘nonunique’ }.
Operación (Operation)
Una operación se define por el nombre, el tipo, los parámetros y restricciones para invocar
un comportamiento asociado sobre un clasificador como una clase. Representa al
comportamiento de un clasificador. Una operación define un servicio que se puede requerir
de cualquier objeto de una clase.
Un método es una implementación de una operación. Cada operación no abstracta tiene un
método con el algoritmo ejecutable. En una jerarquía de herencia puede haber varios
métodos para la misma operación (polimorfismo). En la figura a.2.7, se muestra el
elemento operación y sus relaciones.
Figura 7.23 Elemento Operation y sus relaciones tomado de [61]
La notación que establece el estándar para definir una operación es la siguiente:
172
[<visibilidad>] <nombre> ‘(‘ [<lista de parámetros>] ‘)’ [‘:’ [<tipo de retorno>] [‘[‘
<multiplicidad> ‘]’] [‘{‘ <propiedad de la operación> [‘,’ < propiedad de la operación >]*
‘}’]]
Donde:
visibilidad: es la visibilidad de la operación. Se define en el punto niveles de
visibilidad.
nombre: es el nombre de la operación.
lista de parámetros: es una lista separada por comas de los parámetros de la
operación.
tipo de retorno: si la operación lo tiene definido es el tipo de datos del valor
devuelto.
multiplicidad: es la multiplicidad del tipo de retorno.
propiedad de la operación: representa un modificador que define la naturaleza de
la operación.
Propiedad (Property)
Una Propiedad define las características estructurales de un clasificador. Se relaciona con la
instancia de una clase a través de un valor o conjunto de valores del tipo de atributo. Una
propiedad puede representar a un atributo y también el final de una asociación.
Una propiedad relacionada con un elemento de asociación como memberEnd o sus
especializaciones representa un extremo de la asociación. El tipo de la propiedad es el tipo
del elemento final de la asociación. La notación que establece el estándar para definir un
atributo es la siguiente:
[<visibilidad>] [‘/’] <nombre> [‘:’<tipo>] [‘[‘<multiplicidad>’]’]
[‘=‘<valor inicial>] [‘{‘<modificador> [‘,’<modificador>]*’}’]
Donde:
visibilidad: es la visibilidad de la propiedad.
‘/’: significa que es un atributo derivado.
nombre: es el nombre de la propiedad; es el único campo obligatorio.
tipo: Es el tipo de clasificador que es la propiedad.
multiplicidad: es la multiplicidad de la propiedad.
valor inicial: es una expresión que define el valor por defecto o valor de una
propiedad.
173
modificador: representa un modificador que se aplica al atributo.
Asociación (Association)
Una asociación describe un conjunto de tuplas cuyos valores se refieren a instancias
tipadas. Es un conjunto ordenado de dos o más clasificadores que define las relaciones
semánticas entre sus instancias.
Una asociación proporciona las conexiones, con las cuales los objetos de diversas clases
pueden interactuar. Un enlace es una instancia de una asociación y se define como una lista
ordenada de referencias a objetos.
Cada conexión de una asociación a una clase se llama extremo de la asociación. Los
extremos de la asociación pueden tener nombres denominados nombre de rol y visibilidad.
En la figura 7.24, se muestra el elemento Association y sus relaciones.
Figura 7.24 Elemento Association y sus relaciones tomado de [61]
Diagrama de paquetes (Packages Diagram)
Un paquete se utiliza para agrupar elementos, y proporciona un espacio de nombres para
los elementos agrupados. Sólo los elementos empaquetables pueden ser miembros de un
paquete. En virtud de ser un espacio de nombres, un paquete puede importar tanto los
miembros individuales de otros paquetes, o todos los miembros de otros paquetes. Además
un paquete se puede unir a otros paquetes. En la figura 7.25, se muestra el elemento
package y sus relaciones.
174
Figura 7.25 Elemento package y sus relaciones tomado de [61]
7.2.3 Superstructure
El paquete UML especifica el metamodelo de Superestructura UML. Los paquetes que lo
conforman tienen que ver con el modelado estructural y de comportamiento. Como se
observa en la figura 7.18, el metamodelo UML reúsa el paquete InfrastructureLibrary
importando y especializando todos las metaclases que pertenecen a la InfrastructureLibrary.
El paquete kernel es el núcleo mismo de UML, y las metaclases de cualquier otro paquete
están directa o indirectamente relacionados con este. Está compuesto por clases,
asociaciones y paquetes. Estos elementos son reusados en gran parte del paquete
Constructs. El paquete Kernel es similar al paquete Constructs de la InfrastructureLibrary,
pero añade elementos adicionales a las construcciones de modelado que no son necesarios
para cumplir con la alineación con MOF. En la figura 7.26, se puede ver la relación del
paquete Kernel con el paquete Constructs.
Figura 7.26 Paquetes de InfrastructureLibrary
En este trabajo se utilizan especialmente los elementos del paquete Classes y sus relaciones.
Estos están relacionados con los conceptos básicos del modelado con UML.
175
El paquete kernel es la parte central del modelado con UML, representa los conceptos
fundamentales del modelado con UML, incluyendo: clases, asociaciones, y los paquetes.
Reutiliza principalmente la biblioteca de infraestructura (Infrastructure Library), ya que
muchos de estos conceptos son los mismos que los que se utilizan en, por ejemplo, MOF.
Los elementos del metamodelo UML 2 utilizados en esta tesis son:
Paquete (Package)
Clase (Class)
Asociación (Association)
Propiedad (Property)
Operación (Operation)
Interfaces (Interface)
El kernel de UML toma del paquete Constructs perteneciente al nucleo de la
InfratructureLibrary los elementos: Clase, propiedades, operaciones, asociaciones entre
clases y paquete. Estos elementos fueron desarrollados en la sección anterior referida al
tema Constructs. En relación al paquete Kernel falta desarrollar el elemento Interface que
se desarrolla en la siguiente sección.
Interface (from Interfaces)
El elemento interfaz es utilizado en este trabajo para la definición de las clases que exponen
las operaciones públicas que pueden ser accedidas por otros componentes de una
aplicación.
Como se muestra en la figura 7.27, una interfaz es un tipo de clasificador que representa la
declaración de una colección de operaciones y/o atributos que definen la fachada que
expone un clasificador. Los atributos se declaran en forma abstracta y no necesariamente
tienen que existir en el clasificador que implementa la interfaz.
Las Interfaces son declaraciones que no pueden ser instanciadas; si se puede instanciar el
clasificador que implementa las operaciones de la interface y que se vincula con la interface
mediante la declaración de todas las operaciones de la esta.2.
El clasificador instanciable tiene que ajustarse a la interface que expone la fachada
abstracta.2. Una interface puede exponer las operaciones de varios clasificadores y un
clasificador puede implementar las operaciones de varias interfaces.
Una interfaz especifica un contrato, las instancias de un clasificador que implementa la
interfaz deben cumplir con el contrato. La interface puede restringir por medio de pre y
post-condiciones la interacción de los clasificadores que acceden a las operaciones públicas
expuestas en la fachada de la interface.
176
La relación entre una clase y un interfaz se conoce como realización.
La relación de realización entre la interfaz y un clasificador significa que el clasificador
implementa las características definidas en la interfaz relacionada y la de sus padres.
Figura 7.27 Elemento Interface y sus relaciones tomado de [61]
7.2.4 Perfiles (Profiles)
En la presente tesis se utilizan los perfiles UML con el propósito de extender el
metamodelo UML con elementos propios de la plataforma Java EE.
Los perfiles UML son un mecanismo de extensión y adaptación de metaclases de
metamodelos con un objetivo determinado. En la sección 2.3.6 de “Perfiles UML” se
explican los conceptos básicos y una forma estructurada para su elaboración. En esta
sección se explica los elementos del paquete Profiles de la Superstructura y su relación con
la librería Infratructure.
En el paquete Profiles de la InfrastructureLibrary se definen los elementos y el
funcionamiento de los perfiles UML. Es mediante la utilización de construcciones
auxiliares que el paquete Profiles de la Superstructure UML se extiende o se combina con
el contenido del paquete Profiles de la InfrastructureLibrary. En la figura 7.28, se observa
la relación de dependencia entre los paquetes Profiles de la Infrastructure y de la
Superstructure de UML.
177
Figura 7.28 Dependencia entre paquetes Profiles
Los mecanismos que se utilizan para definir Perfiles son: estereotipos (stereotypes),
restricciones (constraints), y valores etiquetados (tagged values). En la figura 7.29, se
muestran los elementos del paquete Profiles de la Superstructure. Se puede ver que un
elemento Package está compuesto por elementos tipo Stereotype. El elemento Profile
extiende al paquete package.
La metaclase Stereotype tiene una semántica similar a la de una metaclase Class debido a
que es una especialización de esta última.2. A los estereotipos es posible definirles
restricciones, que imponen condiciones sobre los elementos del metamodelo que han sido
estereotipados. Los valores etiquetados son atributos de la metaclase Stereotype y
adquieren la semántica definida para la metaclase Property. Se puede definir asociaciones
entre estereotipos y asociaciones entre estereotipos y cualquier otra clase del metamodelo
de referencia.2.
Figura 7.29 Los elementos del paquete Profiles, tomado de [61]
178
7.3 Anexo 3. Caso de Estudio de la RAC
En este anexo se desarrolla uno de los casos de estudio donde se aplicaron las
transformaciones propuestas. Se aplica el método de trabajo propuesto en la sección 1.3 del
capítulo 1 para lograr el objetivo que partiendo desde un modelo técnico del negocio
BPMN 2 se pueda obtener un prototipo conformado por componentes de código fuente
Java EE. Este es uno de los casos de estudio que se utilizó para validar la propuesta de este
trabajo de tesis y consiste en la implementación de un sistema de guardia hospitalaria que
utiliza un proceso de RAC (Recepción, Acogida y Clasificación) de pacientes. El sistema
funciona actualmente en el hospital Regional Antonio J Scaravelli, está basado en el
prototipo generado por las transformaciones propuestas. Los procesos y el sistema se han
propuesto para su implementación en toda la provincia (http://www.hospital-
scaravelli.mendoza.gov.ar/index.php/prensa/noticias/95-sigamos-construyendo/194-rac-
propuesto-para-implementar-en-toda-la-provincia).
7.3.1 Planteo del Problema
Los procesos del negocio de este sector utilizan la RAC (Recepción, Acogida y
Clasificación) que tiene como objetivo fundamental mejorar la calidad y eficacia de la
atención sanitaria. La etapa fundamental es la de clasificar y distribuir a los pacientes en
base a sus necesidades. La clasificación permite identificar rápidamente a los pacientes que
están en situación de riesgo vital para definir el orden de atención. Los encargados de
realizar la RAC son los enfermeros. Para la clasificación se utilizan colores que se asignan
a cada paciente según el nivel de gravedad. En la figura 1, se puede observar el proceso
general de la etapa de la RAC.
179
Figura 7.30 Clasificación RAC
La RAC forma parte del proceso de guardia hospitalaria donde se pueden distinguir las
siguientes etapas: la admisión del paciente, la RAC y por último la atención médica.
En la figura 2, se muestra en forma general el proceso de guardia hospitalaria.
Figura 7.31 Esquema general del proceso de RAC
En los siguientes puntos se describe el proceso del caso de estudio:
1_ Una persona necesita atención médica.
2_ El administrativo en admisión:
Solicita el documento nacional de identidad y el carnet de la obra social.
180
Busca al paciente.
Da el alta del paciente si es necesario.
Registra el motivo de asistencia de la persona.
4_ El enfermero de la RAC:
Elige del listado cargado por el administrativo al paciente.
Llama al paciente.
Lo revisa y realiza la RAC.
Clasifica con un color teniendo en cuenta la gravedad del paciente y los
parámetros básicos.
Determina la especialidad médica que lo tiene que atender.
5_ El médico que atiende el paciente:
Selecciona al paciente del listado proveniente de la carga del enfermero.
Realiza la atención médica
Carga el diagnóstico y el destino del paciente. El destino del paciente puede
ser: alta, internación, traslado o solicitud de estudios complementarios).
(Esto se define como un encuentro entre el médico y el paciente).
7.3.2 Modelo del Proceso Técnico BPMN 2
El diseño del diagrama técnico BPMN 2 se elabora siguiendo el marco metodológico
BPMN-Framework y buenas prácticas. En la figura 3, se puede observar que el modelo
técnico BPMN 2 está formado por un Pool compuesto por tres elementos Lane, donde solo
se muestran los artefactos relacionados con la tecnología. Este Pool puede interactuar con
otros Pools donde se definan procesos manuales.
Figura 7.32 Diagrama Técnico BPMN2 del caso de estudio: Sistema de Guardia
Hospitalario
181
En la figura 4, se puede ver el diagrama de la figura 3 en formato gráfico del estándar XMI.
En la figura se han quitado los elementos conectores para facilitar su visualización. A partir
de este archivo XMI se realiza la primera transformación a un modelo UML 2 con la
aplicación de un perfil independiente de la plataforma.
Figura 7.33 Diagrama BPMN 2 con visualizador de formato XMI
7.3.3 Transformación de BPMN 2 a UML 2
En base a las transformaciones QVT y el perfil independiente de la tecnología definidos en
la sección 4.2 del capítulo 4 se genera el modelo UML 2 con perfil independiente de la
plataforma. Este modelo puede ser modificado por cualquier herramienta que cumpla con el
estándar UML 2 y estás modificaciones son tomadas por la transformación siguiente para
su procesamiento.
182
El modelo generado está compuesto por dos paquetes: el paquete entities y el business. En
la figura 5, se muestran los paquetes generados producto de la primera transformación.
Figura 7.34 Componentes generados en la primera transformación
Como resultado de la transformación, en el paquete entities se crean automáticamente las
clases que luego se van a convertir en entidades del negocio (Entity). Parte de las clases
generadas dentro del paquete entities se muestran en el diagrama UML2 de la figura 6 y en
el esquema con el formato XMI de la figura 7.
183
Figura 7.35 Parte del modelo generado en la primera Transformación en el Paquete
entities. Versión Diagrama UML 2.
Figura 7.36 Parte del modelo Generado en la primera Transformación en el Paquete
entities. Versión XMI.
Mientras que en el paquete Business se crean las clases que luego se van a convertir en las
clases que van a exponer los servicios web. Las operaciones de la clase MedicoService
generadas en el interior del paquete business se pueden observar en el diagrama XMI de la
figura 8. Se puede ver que se crea una operación crearEncuentroMédico y se marca como
servicio web, también se crea una operación addencuentromedico. El desarrollador puede
utilizar la operación crearEncuentroMédico para exponer el servicio y la operación
addencuentromedico para la implementación concreta de la creación de un objeto
encuentromedico. También puede eliminar la operación crearEncuentroMedico y dejar solo
la operación addencuentroMedico anotando la operación como servicio web en el caso que
se requiera.
Es importante destacar que la transformación genera operaciones CRUD por cada elemento
DataStore asociado a un elemento Service Task de BPMN 2. Entonces, el diagrama UML
2 destino no solo se limita a generar un elemento UML 2 por cada elemento BPMN 2, sino
que si existe coincidencia con ciertos patrones genera un conjunto de elementos en el
destino. Esto se explica en detalle en la sección 4.2.
184
Figura 7.37 Modelo Generado en la primera Transformación en el Paquete Business.
Versión XMI.
7.3.4 Transformación de UML2 a UML2 con perfil Ejb3.1-JPA2
En base al modelo generado en la primera transformación se genera la segunda
transformación de un diagrama UML 2 con perfil independiente de la plataforma a un
diagrama UML 2 con perfil Java EE. En las figuras 9, 10, 11 y 12 se puede observar que
elementos como: clases, atributos, operaciones y asociaciones tienen anotaciones
específicas de la plataforma Java EE. En la sección 4.3 del capítulo 4, se describe en detalle
la Transformación de UML2 a UML2 con perfil Ejb3.1-JPA2.
Se puede observar en la figura 9, las asociaciones y entidades generadas a partir del modelo
UML2 origen. A diferencia del modelo origen, al nuevo modelo se le aplica un perfil
dependiente de la tecnología utilizada, que en este caso es JavaEE. La definición del perfil
JPA 2 se explica en el punto 4.3.3 del capítulo 4. Por ejemplo, las asociaciones entre clases
son anotadas con un estereotipo dependiente de la tecnología con nombre Association.
185
Figura 7.38 Modelo resultante de la Transformación de un modelo UML2 a un modelo
UML 2 del Paquete Entities
En la figura 10, se muestra la entidad EncuentroMedico que contiene el atributo
encuentroMedicoItem anotado con el estereotipo Association. También podemos apreciar
en la figura los atributos correspondientes a la anotación aplicada, donde la transformación
QVT generó los valores por defecto de los atributos Fetch y Type.
186
Figura 7.39 Perfil Association aplicado a la propiedad encuentroMedicoItem
Como se explica en la sección 4.3 del capítulo 4, está segunda transformación toma las
clases UML2 del paquete Business y genera a estas con anotaciones Stateless y
WebService. Además por cada clase se genera una interface para el acceso local y remoto
de los métodos implementados, las interfaces tienen aplicadas las anotaciones
<<Local,Remote>>.
La clases generadas en el paquete Business heredan de la clase AbstractEntityService. Esta
clase no puede ser modificada en el modelo UML2 porque es una clase cuyos elementos
son fijos y son generados posteriormente en la transformación a código fuente.
En la figura 11, se muestran los componentes JavaEE generados en el paquete business
como producto de la ejecución de la segunda transformación.
Figura 7.40 Componentes JavaEE del Paquete Business generados en la Segunda
Transformación
Las operaciones de las clases dentro del paquete business permanecen en el caso de las
operaciones básicas, marcadas con las anotaciones del perfil independiente: créate, update,
deactivate y search.
En el caso de las operaciones con anotaciones para permitir el acceso de los métodos vía
WebServices se le aplica la anotación WebMethod del perfil Java EE. El desarrollador
puede aplicar la anotación WebMethod a cualquier operación para que luego se puea
exponer como servicio web.
En la figura 12, se puede observar las operaciones de la clase MedicoServiceSessionBean
generados por la transformación.
187
Figura 7.41 Detalle de los Componentes de la Clase MedicoServiceSessionBean
7.3.5 Transformación con Acceleo
La transformación definida con la herramienta Acceleo y explicadas en la sección 4.4 del
capítulo 4 se aplican al modelo UML 2 con perfiles Java EE. El destino de la
transformación son los componentes de código fuente JavaEE que pueden desplegarse en
cualquier servidor de aplicaciones compatible con el estándar. Estos componentes JavaEE
integran a un prototipo que es el producto final de las transformaciones propuestas.
En la figura 13, puede observarse la estructura de elementos generados para el caso de
estudio. Los elementos generados tienen una alta trazabilidad con el modelo UML2
dependiente de la plataforma, con el modelo UML2 independiente de la plataforma y con el
modelo de procesos técnico BPMN2. Esta trazabilidad es un buen indicador de
alineamiento entre procesos del negocio y el software que automatiza esos procesos.
188
Figura 7.42 Estructura de elementos Java EE generados por la transformación Acceleo
En la figura 14, se muestra un ejemplo de una parte de la transformación a código fuente
Java EE. En la parte de arriba de la figura está definida la clase MedicoServiceSessionBean
que tiene anotaciones Stateless y Webservice, una relación de asociación con la clase
AbstractEntityService y de realización con la clase MedicoServiceInterface. La clase está
compuesta por una operación con nombre addEncuentroMedico marcada con la operación
de creación de objetos Create. Esta operación tiene como parámetro una clase de tipo
EncuentroMedico. En la parte de abajo de la figura 14, podemos ver que la transformación
Acceleo genera el código Java EE teniendo en cuenta los elementos del modelo origen y
sus anotaciones relacionadas.
189
Figura 7.43 Ejemplo de Código Fuente Generado para Clase Stateless
En la figura 15, podemos observar el resultado de la transformación de una Clase con
estereotipo Entity a una Clase Entity JavaEE que puede ser persistida en una tabla con
nombre EncuentroMedico. Se puede ver también en la figura que se genera el código
extend relacionado con la relación de Generalización especificada en el modelo origen. Las
asociaciones del modelo origen son transformados en atributos con anotaciones como
@OneToMany de acuerdo a como se definen las asociaciones con el estándar de
persistencia de java JPA2.
Figura 7.44 Ejemplo de Código Fuente Generado para Clase Entity
190
7.3.6 Conclusiones
En este anexo, se ha presentado en forma sintética uno de los casos de estudios reales sobre
el que se han aplicado las transformaciones desarrolladas en este trabajo de tesis. Este caso
se ha utilizado para demostrar el funcionamiento y validar las transformaciones y perfiles
propuestos. El objetivo de anexo ha sido describir las tres transformaciones desarrolladas
para cumplir con el objetivo de la tesis de 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.
191
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
--Transformación de nivel superior de un modelo BPMN 2 --a un modelo UML 2 transformation bpm2uml2(bpmn2:bpmn2, uml2 :uml) { key Class{name}; key Operation{name}; key Entity{base_Class}; key Enumeration{name}; --Crea el modelo UML 2 en el destino top relation ModelBpmnToModelUml { enforce domain uml2 u : uml::Model { }; } --Crea el paquete entities en el modelo UML 2 destino top relation generaPackageEntities{ enforce domain uml2 p1:uml::Package{ name = 'entities' }; enforce domain uml2 m:uml::Model{ packagedElement = p1 : uml::Package{} }; when{ ModelBpmnToModelUml(m); }} --Crea el paquete business en el modelo UML 2 destino top relation generaPackageBusiness{ enforce domain uml2 p1:uml::Package{ name = 'business' }; enforce domain uml2 m:uml::Model{ packagedElement = p1 : uml::Package{} }; when{ ModelBpmnToModelUml(m); }} --El elemento DataStore de Bpmn 2 se transforma en clases y --asociaciones UML 2 dentro del Package Entities. top relation DataStoreToClass { pn: String; pnlane: String; m:uml::Model; st1:perfil_independiente::Entity; st2:perfil_independiente::Entity; st21:perfil_independiente::Entity; st3:perfil_independiente::Entity; st4:perfil_independiente::Entity; st6:perfil_independiente::Entity; st7:perfil_independiente::Entity; checkonly domain bpmn2 lane:bpmn2::Lane { name =pnlane }; checkonly domain bpmn2 datastore:bpmn2::DataStoreReference{ name = pn, dataStoreRef = ds : bpmn2::DataStore {}};
192
enforce domain uml2 c1:uml::Class{ name = getNombreClase(pn)}; enforce domain uml2 c2:uml::Class{ name = getNombreClase(pn+'Item')}; enforce domain uml2 c21:uml::Class{ name =getNombreClase('Tipo'+pn)}; enforce domain uml2 c7:uml::Class{ name =getNombreClase(pnlane) }; enforce domain uml2 p:uml::Package { packagedElement = c1: uml::PackageableElement::Class { name =getNombreClase(pn) }, packagedElement = c2: uml::PackageableElement::Class { name =getNombreClase(pn+'Item') }, packagedElement = c21: uml::PackageableElement::Class { name =getNombreClase('Type'+pn) }, packagedElement = c3: uml::PackageableElement::Class { name ='EntityGeneral' }, packagedElement = c4: uml::PackageableElement::Class { name ='User' }, packagedElement = c5: uml::Enumeration { name ='State'+getNombreClase(pn) }, packagedElement = c6: uml::PackageableElement::Class { name ='Company' }, packagedElement = c7: uml::PackageableElement::Class { name =getNombreClase(pnlane) } }; when{ generaPackageEntities(p, m); } where{ DataStoreToClassEntity(ds,c1,c2,c21,c3,c4,c6,st1,st2,st21,st3,st4,st6); --Asociacion OneToMany con Clase Item AsociacionOneToManyItem(c2,c1,p); AtributosClaseItem(c2); AtributosClaseTipo(c21); --Asociacion ManyToOne con Clase Tipo AsociacionManyToOne(c21,c2,p); GeneralizacionClaseGeneral(c3,c1); GeneralizacionClaseGeneral(c3,c2); GeneralizacionClaseGeneral(c3,c21); GeneralizacionClaseGeneral(c3,c4); GeneralizacionClaseGeneral(c3,c6); AtributosGenerales(c3); --Asociacion ManyToOne con Clase Usuario AsociacionManyToOne(c4,c3,p); --Asociacion ManyToOne con Clase Empresa AsociacionManyToOne(c6,c3,p); AsociacionEnumerationEstado(c5,c1); AtributosUsuario(c4);
193
AtributosEmpresa(c6); LaneToClassEntity(lane,c7,st7); GeneralizacionClaseGeneral1(c3,c7); --Asociacion ManyToOne con Clase Lane AsociacionManyToOneClaseLane(c7,c1,p); } } ---Crea la asociación entre Clase y ClaseItem relation AsociacionOneToManyItem { checkonly domain uml2 c1 : Class { }; enforce domain uml2 c : Class { ownedAttribute = src_prop : uml::Property { aggregation = uml::AggregationKind::composite, name = getNombreAsociacion(c.name), type =c1: uml::Class{}, upperValue = upv : uml::LiteralUnlimitedNatural { value = -1 }, lowerValue=lowerValue:uml::LiteralInteger{ value =1 }, association = asoc : uml::Association { name =getNombreAsociacion(c1.name), ownedEnd = propiedad : uml::Property { type = c : uml::Class {}, upperValue =upperValue22:uml::LiteralUnlimitedNatural{ value =1 }, lowerValue=lowerValue22:uml::LiteralInteger{ value =1 }} } } }; enforce domain uml2 p:uml::Package { packagedElement = asoc: uml::Association{ } }; } ---Crea la Generalización con clase General relation GeneralizacionClaseGeneral { checkonly domain uml2 c2: Class { }; enforce domain uml2 c : Class { generalization = gen : uml::Generalization { general = c2 : uml::Class { } } };} ---Crea la relación de Generalización con clase EntityGeneral relation GeneralizacionClaseGeneral1 { checkonly domain uml2 c2: Class { }; enforce domain uml2 c : Class { generalization = gen : uml::Generalization { general = c2 : uml::Class {
194
} } }; } --Aplica el estereotipo Entity a la clase generada del elemento DataStore relation DataStoreToClassEntity{ pn : String; checkonly domain bpmn2 datastore:bpmn2::DataStore{}; enforce domain uml2 c1:uml::Class{}; enforce domain uml2 c2:uml::Class{}; enforce domain uml2 c21:uml::Class{}; enforce domain uml2 c3:uml::Class{}; enforce domain uml2 c4:uml::Class{}; enforce domain uml2 c6:uml::Class{}; enforce domain uml2 dst1:perfil_independiente::Entity { base_Class = c1:uml::Class {} }; enforce domain uml2 dst2:perfil_independiente::Entity { base_Class = c2:uml::Class {} }; enforce domain uml2 dst21:perfil_independiente::Entity { base_Class = c21:uml::Class {} }; enforce domain uml2 dst3:perfil_independiente::Entity { base_Class = c3:uml::Class {} }; enforce domain uml2 dst4:perfil_independiente::Entity { base_Class = c4:uml::Class {} }; enforce domain uml2 dst6:perfil_independiente::Entity { base_Class = c6:uml::Class {} }; } --Aplica el estereotipo Entity a la clase generada del elemento Lane relation LaneToClassEntity{ checkonly domain bpmn2 lane:bpmn2::Lane {}; enforce domain uml2 c1:uml::Class{}; enforce domain uml2 dst1:perfil_independiente::Entity { base_Class = c1:uml::Class {} }; } --Transformación de un elemento Participant de BPMN 2.0 a una clase UML 2 top relation ParticipantToClass{ pn : String; m:uml::Model; st1:perfil_independiente::Entity; checkonly domain bpmn2 b :bpmn2::Definitions { rootElements = colab : bpmn2::Collaboration{ participants = partic : bpmn2::Participant { name = pn }}}; enforce domain uml2 p:uml::Package { packagedElement = c : uml::PackageableElement::Class { name =getSinAcentos(getNombreClase(pn))}}; when { generaPackageEntities(p,m);}
195
where { ParticipantToClassEntity(partic,c,st1);}} ---Aplica el estereotipo Entity a la clase UML 2 generada a partir del -- elemento Participant de BPMN 2.0. relation ParticipantToClassEntity{ checkonly domain bpmn2 partic : bpmn2::Participant{}; enforce domain uml2 c:uml::Class{}; enforce domain uml2 dst:perfil_independiente::Entity {base_Class = c : uml::Class {}};} --En el caso que el elemento Process no tenga elementos Lane. --Se genera una clase por cada elemento Process en el paquete business --La Clase UML 2 generada se marca con la anotación WebService top relation ProcessToClass { pn : String; m:uml::Model; st1:perfil_independiente::WebService; checkonly domain bpmn2 b :bpmn2::Definitions {}; checkonly domain bpmn2 proceso:bpmn2::Process{ isExecutable = true, name = pn }; enforce domain uml2 p:uml::Package{ packagedElement = c : uml::Class {}}; enforce domain uml2 c:uml::Class{ name = getNombreClase(pn)+'Service' }; when { proceso.laneSets.lanes->size()=0; generaPackageBusiness(p,m); } where { LaneToClassWebService1(proceso,c,st1); }} ---Aplica el estereotipo WebService a la clase generada a partir del --elemento Lane relation LaneToClassWebService1{ pn : String; checkonly domain bpmn2 lane:bpmn2::Process{}; enforce domain uml2 c1:uml::Class{}; enforce domain uml2 dst1:perfil_independiente::WebService { base_Class = c1:uml::Class {} };} --En el caso que el elemento Process tenga más de un elemento Lane. --Se genera una clase por cada elemento Lane en el paquete business --La Clase UML 2 generada se marca con la anotación WebService top relation LaneToClass{ pn : String; m:uml::Model; st1:perfil_independiente::WebService; checkonly domain bpmn2 definitions :bpmn2::Definitions { rootElements = process : bpmn2::Process { isExecutable = true }}; checkonly domain bpmn2 lane:bpmn2::Lane { name =pn}; enforce domain uml2 p:uml::Package{ packagedElement = c : uml::Class {}}; enforce domain uml2 c:uml::Class{ name = getNombreClase(pn)+'Service'}; when { process.laneSets.lanes->size()>0; generaPackageBusiness(p,m);} where { LaneToClassWebService(lane,c,st1); }} --Aplica el estereotipo WebService a la clase generada a partir del -- elemento Lane
196
relation LaneToClassWebService{ checkonly domain bpmn2 lane:bpmn2::Lane {}; enforce domain uml2 c1:uml::Class{}; enforce domain uml2 dst1:perfil_independiente::WebService { base_Class = c1:uml::Class {} };} ---Genera una clase UML 2 en base a un elemento Lane de BPMN 2.0 ---Aplica el estereotipo Entity a la clase UML 2 generada top relation LaneToEntityClass{ pn : String; m:uml::Model; st1:perfil_independiente::Entity; --Verifica que el proceso es ejecutable checkonly domain bpmn2 definitions :bpmn2::Definitions { rootElements = process : bpmn2::Process { isExecutable = true}}; checkonly domain bpmn2 lane:bpmn2::Lane { name =pn}; enforce domain uml2 p:uml::Package{ packagedElement = c : uml::Class {}}; enforce domain uml2 c:uml::Class{ name = getNombreClase(pn)}; when { process.laneSets.lanes->size()>0; generaPackageEntities(p,m);} where { LaneToClassEntity1(lane,c,st1);}} ---Aplica el estereotipo Entity a la clase generada a partir --del elemento Lane relation LaneToClassEntity1{ checkonly domain bpmn2 lane:bpmn2::Lane {}; enforce domain uml2 c1:uml::Class{}; enforce domain uml2 dst1:perfil_independiente::Entity {base_Class = c1:uml::Class {}};} --Crea una Operación UML 2 a partir un elemento ServiceTask de BPMN 2.0 --Aplica la Anotacion Independiente de la Tecnología sobre la operacion --La anotación aplicada se llama WebMethod top relation ServiceToOperation{ pn : String; checkonly domain bpmn2 d:bpmn2::Definitions {}; checkonly domain bpmn2 b :bpmn2::ServiceTask { lanes = lane1 : bpmn2::Lane {}, name =pn }; enforce domain uml2 p:uml::Package{ packagedElement = c : uml::Class {} }; enforce domain uml2 src:uml::Operation{ name = getNombreOperacion(pn) }; enforce domain uml2 c:uml::Class{ ownedOperation = src : uml::Operation { name =getNombreOperacion(pn) }}; --Se aplica la anotación WebMethod sobre la operación UML 2 enforce domain uml2 dst:perfil_independiente::WebMethod { base_Operation = src : uml::Operation {}}; when { LaneToClass(d,lane1,p,c); }} ---Crea Operaciones y genera Anotaciones Independientes de la --Tecnología sobre operaciones generadas desde el componente DataStore top relation OperacionGeneradaDataStore
197
{ checkonly domain bpmn2 d:bpmn2::Definitions {}; checkonly domain bpmn2 association:bpmn2::Association { targetRef = tr : bpmn2::DataStoreReference { dataStoreRef = ds : bpmn2::DataStore { } }, sourceRef = fn : bpmn2::ServiceTask { }}; checkonly domain bpmn2 lane:bpmn2::Lane{ flowNodeRefs = fn : bpmn2::ServiceTask {}}; enforce domain uml2 p:uml::Package{ packagedElement = clase : uml::Class {} }; enforce domain uml2 clase:uml::Class{ --Operación add(agregar) ownedOperation = op1 : uml::Operation { name = 'add'+getNombreOperacion(tr.name), ownedParameter = par1 : uml::Parameter { name = getNombreOperacion(tr.name.toLower()), type = datastore_class:uml::Class{ name =getNombreClase(tr.name) }}}, --Operación change(modificar) ownedOperation = op2 : uml::Operation { name = 'change'+getNombreOperacion(tr.name), ownedParameter = par2 : uml::Parameter { name = getNombreOperacion(tr.name.toLower()), type = datastore_class:uml::Class{ name =getNombreClase(tr.name) } }}, --Operación cancel(anular) ownedOperation = op3 : uml::Operation { name ='cancel'+ getNombreOperacion(tr.name), ownedParameter = par3 : uml::Parameter { name = getNombreOperacion(tr.name.toLower()), type = datastore_class:uml::Class{ name =getNombreClase(tr.name) } } }, --Operación query1(consultar1) ownedOperation = op4 : uml::Operation { name = 'query1'+ getNombreOperacion(tr.name), ownedParameter = par44 : uml::Parameter { name = getNombreOperacion(tr.name.toLower()), type = datastore_class:uml::Class{ name =getNombreClase(tr.name) } }, ownedParameter = par55 : uml::Parameter { direction = uml::ParameterDirectionKind::return, name = getNombreOperacion(tr.name.toLower()), type = datastore_class:uml::Class{ name =getNombreClase(tr.name) } } }, --Operación query2(consultar2) ownedOperation = op5 : uml::Operation { name = 'query2'+getNombreOperacion(tr.name), ownedParameter = par4 : uml::Parameter { direction = uml::ParameterDirectionKind::return, name = getNombreOperacion(tr.name.toLower()), type = datastore_class:uml::Class{ name =getNombreClase(tr.name) }, upper = -1, upperValue = up : uml::LiteralUnlimitedNatural{
198
value = -1 } } } }; --Aplica la anotación Create sobre la operación enforce domain uml2 dst1:perfil_independiente::Create { base_Operation =op1:uml::Operation {} }; enforce domain uml2 dst2:perfil_independiente::Update { base_Operation =op2:uml::Operation {} }; enforce domain uml2 dst3:perfil_independiente::Deactivate { base_Operation =op3:uml::Operation {} }; enforce domain uml2 dst4:perfil_independiente::Search { base_Operation =op4:uml::Operation {} }; enforce domain uml2 dst5:perfil_independiente::Search { base_Operation =op5:uml::Operation {} }; when { LaneToClass(d,lane,p,clase); } } ---Crea la asociación entre la clase Item y la Clase Tipo relation AsociacionManyToOne { checkonly domain uml2 c1: Class { }; enforce domain uml2 c2 : Class { ownedAttribute = src_prop : uml::Property { type =c1: uml::Class{ }, upperValue = upv : uml::LiteralUnlimitedNatural { value = 1 }, lowerValue=lowerValue:uml::LiteralInteger{ value =1 }, association = asoc : uml::Association { --name='asoc', ownedEnd = propiedad : uml::Property { type = c2 : uml::Class {}, upperValue =upperValue22:uml::LiteralUnlimitedNatural{ value =-1 }, lowerValue=lowerValue22:uml::LiteralInteger{ value =1 }} } } }; enforce domain uml2 p:uml::Package { packagedElement = asoc: uml::Association{ } };
199
} --Crea la asociación entre la clase General y la Clase Lane relation AsociacionManyToOneClaseLane { checkonly domain uml2 c1: Class { }; enforce domain uml2 c2 : Class { ownedAttribute = src_prop : uml::Property { name = getNombreAsociacion(c2.name), type =c1: uml::Class{ }, upperValue = upv : uml::LiteralUnlimitedNatural { value = 1 }, lowerValue=lowerValue:uml::LiteralInteger{ value =1 }, association = asoc : uml::Association { name = getNombreAsociacion(c1.name), ownedEnd = propiedad : uml::Property { type = c2 : uml::Class {}, upperValue =upperValue22:uml::LiteralUnlimitedNatural{ value =-1 }, lowerValue=lowerValue22:uml::LiteralInteger{ value =1 }} } } }; enforce domain uml2 p:uml::Package { packagedElement = asoc: uml::Association{ } }; } --Crea la asociación entre la clase General y la Clase Estado relation AsociacionEnumerationEstado { checkonly domain uml2 c1: Enumeration { }; enforce domain uml2 c2 : uml::Class { ownedAttribute = src_prop : uml::Property { name = 'state', type =c1: uml::Enumeration{ } } }; } --Crea atributos comunes a todas las clases padre relation AtributosGenerales { primDataTypeName: String; enforce domain uml2 c : Class { ownedAttribute = prop_descripcion : uml::Property { name = 'description', type = tipo_prop_descripcion : uml::PrimitiveType{ name = 'String' } }, ownedAttribute = prop_fecha_reg : uml::Property {
200
name = 'registrationDate', type = tipo_prop_fecha_reg : uml::PrimitiveType{ name = 'Date' } }, ownedAttribute = prop_version : uml::Property { name = 'version', type = tipo_prop_version : uml::PrimitiveType{ name = 'String' } }, ownedAttribute = prop_estado : uml::Property { name = 'active', type = tipo_prop_estado : uml::PrimitiveType{ name = 'Boolean' } } }; } --Crea atributos de clase Item relation AtributosClaseItem { primDataTypeName: String; enforce domain uml2 c : Class { ownedAttribute = prop_nombre : uml::Property { name = 'description', type = tipo_prop_nombre: uml::PrimitiveType{ name = 'String' } } }; } --Crea atributos de clase Tipo relation AtributosClaseTipo { primDataTypeName: String; enforce domain uml2 c : Class { ownedAttribute = prop_nombre : uml::Property { name = 'description', type = tipo_prop_nombre: uml::PrimitiveType{ name = 'String' } } }; } --Crea atributos de clase Usuario relation AtributosUsuario { primDataTypeName: String; enforce domain uml2 c : Class { ownedAttribute = prop_nombre : uml::Property { name = 'name', type = tipo_prop_nombre: uml::PrimitiveType{ name = 'String' } }, ownedAttribute = prop_contrsenia : uml::Property { name = 'pasword', type = tipo_prop_contrasenia: uml::PrimitiveType{ name = 'String' } } };
201
} --Crea atributos de clase Estado relation AtributosEstado { enforce domain uml2 c : Class { ownedAttribute = prop_estado : uml::Property { name = 'description', type = tipo_prop_estado : uml::PrimitiveType{ name = 'String' } } }; } --Crea atributos de clase Empresa relation AtributosEmpresa { enforce domain uml2 c : Class { ownedAttribute = prop_estado : uml::Property { name = 'description', type = tipo_prop_estado : uml::PrimitiveType{ name = 'String' } } }; } --Query para la generación de nombres de elementos estándarizados query getNombreOperacion( stNombre: String ) : String { getSinAcentos(stNombre.trim().firstToLower().replace(' ','')) } query getNombreAtributo( stNombre: String ) : String { getSinAcentos(stNombre.trim().firstToLower().replace(' ','')) } query getNombreClase( stNombre: String ) : String { getSinAcentos(stNombre.trim().firstToUpper().replace(' ','')) } query getNombreAsociacion( stNombre: String ) : String { getSinAcentos(stNombre.trim().firstToLower().replace(' ','')) } query getSinAcentos(stCadena: String) : String { getSinAcentos_u(getSinAcentos_o(getSinAcentos_i(getSinAcentos_e(getSinAcentos_a(stCadena))))) } query getSinAcentos_a(stCadena: String) : String { stCadena.replace('á','a') } query getSinAcentos_e(stCadena: String) : String { stCadena.replace('é','e') } query getSinAcentos_i(stCadena: String) : String { stCadena.replace('í','i') } query getSinAcentos_o(stCadena: String) : String { stCadena.replace('ó','o') } query getSinAcentos_u(stCadena: String) : String { stCadena.replace('ú','u') } }
202
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
--Transformación 2-Transformación de UML2 a UML2 con perfil Ejb3.1-JPA2 --Declaración con nombre (uml2ejb3) que tiene como modelo origen a un modelo UML 2 --(con perfil independiente de la plataforma) con nombre uml --y destino a un modelo UML 2 (con perfil Ejb3.1-JPA2) denominado uml. -- transformation uml2ejb3 ( source : uml, target : uml ) { --La instrucción Key Class{name} permite identificar de forma única --a un elemento clase utilizando como clave a la propiedad name. key Class{name}; --La Relación ModelUmlToModelEjb3 transforma un modelo UML2 que puede --tener agregados del desarrollador como clases, atributos y operaciones --en un modelo UML 2 específico de la plataforma Java EE con las anotaciones --correspondientes. top relation ModelUmlToModelEjb3 { modelName : String; checkonly domain source src : uml::Model { name = modelName }; enforce domain target dst : uml::Model { name = modelName }; where { ModeloUmlToPackageEjb3( src, dst );}} --La postcondición ejecuta la regla de transformación que genera los --paquetes Business y Entities relation ModeloUmlToPackageEjb3 { packageName : String; checkonly domain source srcPkg : uml::Package {packagedElement = srcP : Package { name = packageName}}; enforce domain target dstPkg : uml::Package {packagedElement = dstP : Package { name = packageName }}; where { ModeloUmlToPackageEjb3(srcP, dstP); ClassToEntity(srcP, dstP); ClassToSessionAbstract(srcP, dstP ); } } --Toma las clases del paquete entities y le aplica transformaciones relation ClassToEntity { className : String; st:perfil_jpa2::Entity; checkonly domain source srcP : uml::Package { packagedElement = srcCls:Class { name = className }}; enforce domain target dstP : uml::Package {packagedElement = dstCls : Class { name = className} }; when { srcP.name='entities'; } where { ModeloUmlToPackageEjb3( srcP, dstP); Entidades(srcCls,dstCls); GeneralizacionClaseGeneral(srcCls,dstCls); AtributosEntity(srcCls, dstCls); Asociaciones(srcP,dstP); }
203
} relation Entidades { oName : String; checkonly domain source src : Class {}; enforce domain target dst : Class { }; where{ EntidadIndependiente(src,dst); } } ---Toma las entidades marcadas con la anotación Entity del modelo origen y -- las tranforma en una entidad JPA de Java EE relation EntidadIndependiente { stereotipo: Stereotype; st1:perfil_jpa2::Entity; checkonly domain source src_origen : uml::Class{ }; checkonly domain source src_destino : uml::Class{ }; when { stereotipo= getStereotype ('Entity'); src_origen.isStereotypeApplied(stereotipo); } where { ClaseAnotadaEntity(src_destino,st1);} } --Crea la Generalización con la clase General relation GeneralizacionClaseGeneral { checkonly domain source c1: Class { generalization = gen : uml::Generalization { } }; enforce domain target c2: Class { generalization = gen : uml::Generalization { } }; } --Aplica la anotación Entity a la clase relation ClaseAnotadaEntity { checkonly domain source src : uml::Class{ }; enforce domain target dst:perfil_jpa2::Entity { base_Class = src : uml::Class {} }; } --Genera las asociaciones relation Asociaciones { assocName: String; checkonly domain source src : uml::Package { packagedElement = srcAss : uml::Association { name = assocName }}; enforce domain target dst : uml::Package { packagedElement = dstAss : uml::Association { name = assocName }}; where { AssociationEnds(srcAss,dstAss); }
204
} --Genera los atributos de la entidad relation AtributosEntity { atName : String; checkonly domain source src : Class { }; enforce domain target dst : Class { }; where { AtributosPrimitivosEntity(src,dst); AsociacionAtributosEntityComposite(src,dst); AsociacionAtributosEntityNone(src,dst); } } --Genera los atributos primitivos de la entidad relation AtributosPrimitivosEntity { propName: String; primDataTypeName: String; checkonly domain source src : Class { ownedAttribute = iprop_origen : uml::Property { name=propName, type = tipo_origen : uml::PrimitiveType{ name = primDataTypeName } } }; enforce domain target dst : Class { ownedAttribute = irprop_destino: uml::Property { name=propName, type = tipo_destino : uml::PrimitiveType{ name = primDataTypeName } } }; } --Genera los atributos cuyos tipos son clases relation AsociacionAtributosEntityComposite { atName : String; asociacion:uml::Association; checkonly domain source src : Class { ownedAttribute = src_prop : uml::Property { aggregation = uml::AggregationKind::composite, type =type1:uml::Class{ name=atName } } }; enforce domain target dst : Class { ownedAttribute = dst_prop: uml::Property { name = getNombreAtributo(atName), aggregation = uml::AggregationKind::composite, type =type2:uml::Class{ name =atName } } }; where { ClassToAssociationAtributo(src_prop,dst_prop); } } ---Genera los atributos de la asociación de la entidad relation AsociacionAtributosEntityNone { atName : String; asociacion:uml::Association; checkonly domain source src : Class
205
{ ownedAttribute = src_prop : uml::Property { aggregation = uml::AggregationKind::none, type =type1:uml::Class{ name=atName } } }; enforce domain target dst : Class { ownedAttribute = dst_prop: uml::Property { aggregation = uml::AggregationKind::none, type =type2:uml::Class{ name =atName } } }; where { ClassToAssociationAtributo(src_prop,dst_prop); } } --Genera las asociaciones en los atributos de las entidades relation ClassToAssociationAtributo { atName:String; valorlower:Integer; valorupper:Integer; st:perfil_jpa2::Association; prefix: String; checkonly domain source src :uml::Property { upperValue =upperValue:uml::LiteralUnlimitedNatural{ value =valorupper }, lowerValue=lowerValue:uml::LiteralInteger{ value = valorlower }, association = asoc_origen : uml::Association {} }; enforce domain target dst :uml::Property { upperValue =upperValue11:uml::LiteralUnlimitedNatural{ value =valorupper }, lowerValue=lowerValue11:uml::LiteralInteger{ value =valorlower}, association = asoc_destino : uml::Association {} }; when { AssociationEnds(asoc_origen,asoc_destino); } where { prefix = traerCardinalidad(valorupper,valorlower); AsociacionAnotada (src,dst, st,prefix ); } } --Genera la anotación de la asociación en el atributo relation AsociacionAnotada { className : String; sqltype : String; valorlower:Integer; valorupper:Integer; tipo_fetch:String; checkonly domain source origen :uml::Property { }; checkonly domain source src :uml::Property
206
{ }; enforce domain target dst:perfil_jpa2::Association { base_Property = src : uml::Property { }, type = sqltype, fetch = tipo_fetch }; primitive domain prefix : String; where { sqltype = prefix; tipo_fetch=traerFetch(prefix); } } --Genera las cardinalidad de la asociación relation AssociationEnds { prop_name : String; valuespec:LiteralInteger; valuespec1:LiteralUnlimitedNatural; valorupper:Integer; valorlower:Integer; valorupper1:Integer; st:perfil_jpa2::Association; checkonly domain source src : uml::Association { ownedEnd = p1 : uml::Property { name=prop_name, type = type:uml::Class{}, upperValue =valuespec11:uml::LiteralUnlimitedNatural{ value = valorupper}, lowerValue =valuespec22:uml::LiteralInteger{ value = valorlower}} }; enforce domain target dstp : uml::Association { ownedEnd = p2 : uml::Property { name=prop_name, type=type, upperValue =upperValue:uml::LiteralUnlimitedNatural{ value =valorupper}, lowerValue=lowerValue:uml::LiteralInteger{ value =valorlower}} }; } --Al elemento Class se le agrega una relación de generalización con un clase AbstractEntityService relation ClassToSessionAbstract { checkonly domain source srcP : uml::Package { }; enforce domain target dstP : uml::Package { packagedElement = dstCls : Class { isAbstract =true , name = 'AbstractEntityService'} }; when { srcP.name='business'; } where { ModeloUmlToPackageEjb3( srcP, dstP); ClassToSession(srcP,dstCls,dstP); }} --Transforma las clases uml 2 del modelo origen en clases anotadas --como componentes EJB del tipo Stateless Session Bean relation ClassToSession { className : String; st:perfil_ejb3::Session; st1:perfil_ejb3::WebService; st_interface_local:perfil_ejb3::Local;
207
st_interface_remote:perfil_ejb3::Remote; checkonly domain source src : uml::Package {packagedElement = srcCls:Class { name = className }}; checkonly domain source srcClass : uml::Class { }; enforce domain target dst : uml::Package {packagedElement = dstCls2 : Class { name = className+'SesssionBean', interfaceRealization =interfacel: uml::InterfaceRealization { client = dstCls2 : uml::Class {}, supplier =interface: uml::Interface{}, contract =interface: uml::Interface {}}, generalization = gen : uml::Generalization { general = srcClass : uml::Class {}} }, packagedElement = interface: uml::Interface { name = className+'Interface'}}; where { ClassesAnotada(dstCls2,st,st1 ); Session(srcCls,dstCls2); InterfaceAnotada(interface,st_interface_local,st_interface_remote); OperacionesClases(srcCls, dstCls2); OperacionesInterface(srcCls, interface); }} --Aplica el estereotipo Stateless y WebService a la clase relation ClassesAnotada { className : String; checkonly domain source src : uml::Class {name = className }; enforce domain target dst :perfil_ejb3::Stateless { base_Class = src : uml::Class {}}; enforce domain target dst1 :perfil_ejb3::WebService { base_Class = src : uml::Class {}}; } --Aplica estereotipos JavaEE relation Session { oName : String; checkonly domain source src : Class {}; enforce domain target dst : Class { }; where{ WebServicesIndependiente(src,dst); }} --Aplica el estereotipo Local y Remote a la Interface relation InterfaceAnotada { className : String; checkonly domain source src : uml::Interface { name = className }; enforce domain target dst :perfil_ejb3::Local { base_Interface = src : uml::Interface {} }; enforce domain target dst1 :perfil_ejb3::Remote { base_Interface = src : uml::Interface {} }; } --Genera las operaciones con sus componentes en las clases del modelo destino relation OperacionesClases { oName : String; st:perfil_ejb3::WebMethod; checkonly domain source src : Class { ownedOperation = ope_src : Operation {
208
name = oName}}; enforce domain target dst : Class { ownedOperation = ope_dst : Operation { name = oName}}; where { ParametrosOperaciones(ope_src,ope_dst); OperacionWebMethod(ope_src,ope_dst); OperacionIndependienteCreate(ope_src,ope_dst); OperacionIndependienteUpdate(ope_src,ope_dst); OperacionIndependienteDeactivate(ope_src,ope_dst); OperacionIndependienteSearch(ope_src,ope_dst);}} relation OperacionesInterface { oName : String; checkonly domain source src : Class { ownedOperation = ope_src : Operation { name = oName } }; enforce domain target dst :uml::Interface { ownedOperation = ope_dst : Operation { name = oName } }; where { ParametrosOperaciones(ope_src,ope_dst); } } relation ParametrosOperaciones { atName : String; checkonly domain source src :Operation { }; enforce domain target dst :Operation { }; where { ParametrosOperacionesDetalle(src,dst); } } relation ParametrosOperacionesDetalle { oName : String; nombre_paramuml:String; direccion:uml::ParameterDirectionKind; valorupper:Integer; valorlower:Integer; st:perfil_ejb3::WebMethod; checkonly domain source src :Operation { name = oName, ownedParameter = par_src : uml::Parameter { direction = direccion, name = nombre_paramuml, type = tipo : uml::Class{ } } }; enforce domain target dst :Operation { name = oName, ownedParameter = par_dst : uml::Parameter { direction =direccion, name = nombre_paramuml, type = tipo_dst : uml::Class{
209
name = tipo.name } } }; } --Transformación independiente WebMethod relation OperacionWebMethod { stereotipo: Stereotype; st1:perfil_ejb3::WebMethod; checkonly domain source src_origen : uml::Operation{ }; checkonly domain source src_destino : uml::Operation{ }; when { stereotipo= getStereotype ('WebMethod'); src_origen.isStereotypeApplied(stereotipo); } where { OperacionAnotadaWebMethod(src_destino,st1);} } relation OperacionAnotadaWebMethod { checkonly domain source src : uml::Operation{ }; enforce domain target dst:perfil_ejb3::WebMethod {base_Operation = src : uml::Operation {}}; } ---Transformación independiente Create relation OperacionIndependienteCreate { stereotipo: Stereotype; st1: perfil_independiente::Create; checkonly domain source src_origen : uml::Operation{ }; checkonly domain source src_destino : uml::Operation{ }; when { stereotipo= getStereotype ('Create' ); src_origen.isStereotypeApplied(stereotipo); } where { OperacionAnotadaCreate(src_destino,st1);} } relation OperacionAnotadaCreate { checkonly domain source src : uml::Operation{ }; enforce domain target dst:perfil_independiente::Create {base_Operation = src : uml::Operation {}}; } ---Transformación independiente Update relation OperacionIndependienteUpdate { stereotipo: Stereotype; st1: perfil_independiente::Update; checkonly domain source src_origen : uml::Operation{ }; checkonly domain source src_destino : uml::Operation{ }; when { stereotipo= getStereotype ('Update'); src_origen.isStereotypeApplied(stereotipo); } where { OperacionAnotadaUpdate(src_destino,st1);} } relation OperacionAnotadaUpdate { checkonly domain source src : uml::Operation{ }; enforce domain target dst:perfil_independiente::Update {base_Operation = src : uml::Operation {}}; } ---Transformación independiente Deactivate relation OperacionIndependienteDeactivate { stereotipo: Stereotype; st1: perfil_independiente::Deactivate; checkonly domain source src_origen : uml::Operation{ }; checkonly domain source src_destino : uml::Operation{ }; when
210
{ stereotipo= getStereotype ('Deactivate'); src_origen.isStereotypeApplied(stereotipo); } where { OperacionAnotadaDeactivate(src_destino,st1);} } relation OperacionAnotadaDeactivate { checkonly domain source src : uml::Operation{ }; enforce domain target dst:perfil_independiente::Deactivate {base_Operation = src : uml::Operation {}}; } ---Transformación independiente Search relation OperacionIndependienteSearch { stereotipo: Stereotype; st1: perfil_independiente::Search; checkonly domain source src_origen : uml::Operation{ }; checkonly domain source src_destino : uml::Operation{ }; when { stereotipo= getStereotype ('Search'); src_origen.isStereotypeApplied(stereotipo); } where { OperacionAnotadaSearch(src_destino,st1);} } relation OperacionAnotadaSearch { checkonly domain source src : uml::Operation{ }; enforce domain target dst:perfil_independiente::Search {base_Operation = src : uml::Operation {}}; } --Si la clase origen está anotada con el estereotipo 'WebService' --entonces anota a la clase destino con las anotaciones JavaEE --Stateless y WebService relation WebServicesIndependiente { stereotipo: Stereotype; st1:perfil_ejb3::Stateless; st2:perfil_ejb3::WebService; checkonly domain source src_origen : uml::Class{ }; checkonly domain source src_destino : uml::Class{ }; when { stereotipo= getStereotype ('WebService'); src_origen.isStereotypeApplied(stereotipo);} where { ClaseAnotadaWebService(src_destino,st1,st2);}} relation ClaseAnotadaWebService { checkonly domain source src : uml::Class{ }; enforce domain target dst:perfil_ejb3::Stateless {base_Class = src : uml::Class {}}; enforce domain target dst1:perfil_ejb3::WebService {base_Class = src : uml::Class {}}; } -------------------------------------------------------- query traerFetch(tipo_asociacion:String):String{ if tipo_asociacion='ManyToOne' or tipo_asociacion='OneToOne' then 'EAGER' else 'LAZY' endif } query traerCardinalidad(upper1_owner:Integer,upper2_inverse:Integer) : String { if upper1_owner=-1 and upper2_inverse=1 then 'OneToMany' else if upper1_owner=1 and upper2_inverse=-1 then 'ManyToOne' else if upper1_owner=-1 and upper2_inverse=-1 then
211
'ManyToMany' else 'OneToOne' endif endif endif } -- trae la primera instancia del estereotipo con nombre stname query getStereotype ( stName : String ) : Stereotype { Stereotype.allInstances()->select (x : uml::Stereotype | x.name = stName)->asSequence()->first() } query getNombreAtributo( stNombre: String ) : String { stNombre.trim().firstToLower() } }
212
7.6 Anexo 6. Código Fuente de Acceleo: Transformación de
UML2 con perfil Ejb3.1-JPA2 a Código Fuente JavaEE
En la figura 7.30, podemos ver la estructura del proyecto Acceleo con la descripción de sus
principales componentes. En la sección 4.4, del capítulo cuatro se explican las principales
transformaciones.
Figura 7.45 Paquetes de Infrastructure
A continación se detalla se detalla el código fuente elaborado con Acceleo.
Paquete: org.eclipse.acceleo.module.proyecto_tx5.main
Generate.mtl [comment encoding = UTF-8 /] [module generate('http://www.eclipse.org/uml2/4.0.0/UML')] [import org::eclipse::acceleo::module::proyecto_tx5::main::modules::common/] [import org::eclipse::acceleo::module::proyecto_tx5::main::modules::bodyWebService/] [import org::eclipse::acceleo::module::proyecto_tx5::main::modules::bodySessionBean/] [import org::eclipse::acceleo::module::proyecto_tx5::main::modules::bodyInterface/] [import org::eclipse::acceleo::module::proyecto_tx5::main::modules::bodyEntity/] [template public generateElement(aModel : Model)] [comment @main/] [for (p:Package|aModel.ownedElement->selectByType(Package))]
213
[p.generatePackage()/] [/for] [/template] [template public generatePackage(_package:Package)] [for (p:Package|_package.ownedElement->selectByType(Package))] [p.generatePackage()/] [/for] [for (cls:Class|_package.ownedElement->selectByType(Class))] [cls.generateWebService()/] [/for] [for (cls:Class|_package.ownedElement->selectByType(Class))] [cls.generateSessionBean()/] [/for] [for (interface:Interface|_package.ownedElement->selectByType(Interface))] [interface.generateInterface()/] [/for] [for (cls:Class|_package.ownedElement->selectByType(Class))] [cls.generateEntity()/] [/for] [/template] [template public generateWebService(c:Class) ? (c.hasStereotype('WebService'))] [comment @main/] [file (c.getFullPathFile().trim(), false, 'UTF-8')] [_commentFileBlock()/] [c.packageBlock()/] [importBlock()/] [_commentBodyBlock()/] [c.generateBodyWebService()/] [/file] [/template] [template public generateSessionBean(c:Class) ? (c.hasStereotype('S'))] [comment @main/] [file (c.getFullPathFile().trim(), false, 'UTF-8')] [_commentFileBlock()/] [c.packageBlock()/] [importBlock()/] [_commentBodyBlock()/] [c.generateBodyWebService()/] [/file] [/template] [template public generateInterface(i : Interface)] [comment @main /] [file (i.getFullPathFile().trim(), false)] [_commentFileBlock()/] [i.packageBlock()/] [importBlock()/] [i.generateInterfaceBody()/]
214
[/file] [/template] [template public generateEntity(clase : Class) ? (clase.hasStereotype('Entity'))] [comment @main /] [file (clase.getFullPathFile().trim(), false)] [clase.packageBlock()/] [clase.importEntity()/] [clase.generateBodyEntity()/] [/file] [/template] [query public hasStereotype( e : uml::Element, value: String) : Boolean = not e.getAppliedStereotypes()->select(e:uml::Stereotype | e.name = value)->isEmpty() /]
Paquete: org.eclipse.acceleo.module.proyecto_tx5.main.modules
common.mtl [comment encoding = UTF-8 /] [module common('http://www.eclipse.org/uml2/4.0.0/UML')] [template public packagePath(cl : Classifier)] [cl.getNearestPackage().normalizeName()/] [/template] [template public getFullPathFile(cl : Classifier)] [if (not cl.getNearestPackage().oclIsUndefined())] [cl.getNearestPackage().normalizeName().substituteAll('.', '/').concat('/').concat(cl.name).concat('.java')/] [else] [cl.name.concat('.java')/] [/if] [/template] [template public getInParameter(o : Operation)] [for (p : Parameter | o.ownedParameter) separator(',') ? (p.direction <> ParameterDirectionKind::return)][p.type.name/] [p.name/][/for] [/template] [template public returnTypeOperation(o : Operation)] [if (o.type.oclIsUndefined())]void [o.name/][else][o.type.name/] [o.name/][/if] [/template] [template public importBlock()] import Abstracts.AbstractEntityService; import java.util.*; import entities.*; import javax.ejb.Local; import javax.ejb.Remote; import javax.ejb.Stateless; import javax.persistence.Query; import javax.jws.WebService; import javax.jws.WebMethod; import javax.jws.WebParam; [/template] [template public importEntity()] import Abstracts.AbstractEntity;
215
import java.util.ArrayList; import java.util.Date; import java.util.HashSet; import java.util.List; import java.util.Set; import javax.persistence.Basic; import javax.persistence.CascadeType; import javax.persistence.Entity; import javax.persistence.FetchType; import javax.persistence.JoinColumn; import javax.persistence.ManyToOne; import javax.persistence.OneToMany; import javax.persistence.OneToOne; import javax.persistence.ManyToMany; import javax.persistence.Table; import javax.persistence.Temporal; import javax.persistence.TemporalType; [/template] [template public packageBlock(cl : Classifier)] [if (not cl.getNearestPackage().oclIsUndefined())]package [cl.packagePath()/];[/if] [/template] [template private normalizeName(element : NamedElement)] [if ((element.name = 'package') or (element.name = 'interface') or (element.name = 'class'))][element.name.concat('_')/][else][element.name/][/if] [/template] [template public _commentFileBlock()] /** * Generado con MTL-Acceleo */ [/template] [template public _commentBodyBlock()] /** * @author Ing. Carlos Martinez */ [/template] [template public returnOperationComment()] * @return [/template] [template public paramOperationComment(p : Parameter)] * @param [p.name/] [/template]
bodyEntity.mtl
[comment encoding = UTF-8 /] [module bodyEntity('http://www.eclipse.org/uml2/4.0.0/UML')] [import org::eclipse::acceleo::module::proyecto_tx5::main::modules::common/] [import org::eclipse::acceleo::module::proyecto_tx5::services::stereotypesServices/] [template public generateBodyEntity(c : Class)] @Entity public[if (c.isAbstract)] abstract[/if] class [c.name.toUpperFirst()/][for (superC : Class | c.superClass) before(' extends ') separator(',')] [superC.name/][/for][for (interf : Interface | c.getImplementedInterfaces()) before(' implements ') separator(',')] [interf.name/][/for] { private static final long serialVersionUID = 1L; [for (p : Property | c.getAllAttributes())] [if (p.upper = -1 or p.upper > 1)] [p.propertyAnnotated()/]
216
private List<[p.type.name/]> [p.name/]; [else] [p.propertyAnnotated()/] private [p.type.name/] [p.name/]; [/if] [/for] [for (p : Property | c.getAllAttributes())] public [if (p.upper = -1 or p.upper > 1)]List<[p.type.name/]>[else][p.type.name/][/if] get[p.name.toUpperFirst()/]() { return this.[p.name/]; } public void set[p.name.toUpperFirst()/]([if (p.upper = -1 or p.upper > 1)]List<[p.type.name/]>[else][p.type.name/][/if] p_[p.name/]) { this.[p.name/] = p_[p.name/]; } [/for] [for (p : Property | c.getAssociations().memberEnd)] [if (p.upper = -1 or p.upper > 1)] private List<[p.type.name/]> [p.name/]; [else] private [p.type.name/] [p.name/]; [/if] [/for] [for (o : Operation | c.getOperations())] [o.operationBody()/] [/for] [for (interf : Interface | c.getImplementedInterfaces())] [for (o : Operation | interf.ownedOperation)] [o.operationBody()/] [/for] [/for] } [/template] [template private operationBody(o : Operation)] [for (p : Parameter | o.ownedParameter) ? (p.direction <> ParameterDirectionKind::return)] [paramOperationComment(p)/] [/for] [if (not o.type.oclIsUndefined())] [returnOperationComment()/] [/if] */ public [o.returnTypeOperation()/]([o.getInParameter()/]) { [if (not o.type.oclIsUndefined())] // TODO should be implemented return null; [else] // TODO should be implemented [/if] } [/template] [template private propertyAnnotated (atr :Property) ? (atr.hasStereotype('Association'))] [atr.getStereotype()/] [/template] [query public hasStereotype( e : uml::Element, value: String) : Boolean = not e.getAppliedStereotypes()->select(e:uml::Stereotype | e.name = value)->isEmpty() /]
217
[query public getStereotype(e : uml::Property) :String = attributecardinality(e) /]
bodyInterface.mtl
[comment] Tesis [/comment] [module bodyInterface('http://www.eclipse.org/uml2/2.1.0/UML')/] [import org::eclipse::acceleo::module::proyecto_tx5::main::modules::common/] [import org::eclipse::acceleo::module::proyecto_tx5::common::declaration /] [import org::eclipse::acceleo::module::proyecto_tx5::common::type/] [template public generateInterfaceBody(i : Interface)] @Remote @Local public interface [i.name.toUpperFirst()/] { [for (o : Operation | i.ownedOperation)] [for (p : Parameter | o.ownedParameter) ? (p.direction <> ParameterDirectionKind::return)] [/for] [if (not o.type.name.oclIsUndefined())] [/if] [o.genMethodPrototype()/]; [/for] } [/template]
bodySessionBean.mtl
[comment encoding = UTF-8 /] [module bodySessionBean('http://www.eclipse.org/uml2/4.0.0/UML')] [import org::eclipse::acceleo::module::proyecto_tx5::main::modules::common/] [import org::eclipse::acceleo::module::proyecto_tx5::common::declaration /] [import org::eclipse::acceleo::module::proyecto_tx5::services::typesServices/] [import org::eclipse::acceleo::module::proyecto_tx5::common::type/] [template public generateCuerpoSessionBean(c : Class)] [if (c.hasStereotype('Stateless'))] @Stateless [/if] @WebService public[if (c.isAbstract)] abstract[/if] class [c.name.toUpperFirst()/][for (superC : Class | c.superClass) before(' extends ') separator(',')] [superC.name/][/for][for (interf : Interface | c.getImplementedInterfaces()) before(' implements ') separator(',')] [interf.name/][/for] { private static final long serialVersionUID = 1L; [for (p : Property | c.getAllAttributes())] [if (p.upper = -1 or p.upper > 1)] private List<[p.type.name/]> [p.name/]; [else] private [p.type.name/] [p.name/]; [/if] [/for] [for (p : Property | c.getAllAttributes())] public [if (p.upper = -1 or p.upper > 1)]List<[p.type.name/]>[else][p.type.name/][/if] get[p.name.toUpperFirst()/]() { return this.[p.name/]; } public void set[p.name.toUpperFirst()/]([if (p.upper = -1 or p.upper > 1)]List<[p.type.name/]>[else][p.type.name/][/if] p_[p.name/]) { this.[p.name/] = p_[p.name/]; } [/for]
218
[for (p : Property | c.getAssociations().memberEnd)] [if (p.upper = -1 or p.upper > 1)] private List<[p.type.name/]> [p.name/]; [else] private [p.type.name/] [p.name/]; [/if] [/for] [for (o : Operation | c.getOperations())] @WebMethod [o.genMethodPrototype()/] { [if (not o.type.oclIsUndefined())] [if (o.hasStereotype('Search'))] return super.findAll([o.ownedParameter->select(param : Parameter | param.direction = ParameterDirectionKind::return)->first().genType1()/].class); [/if] [else] [if (o.hasStereotype('Create'))] super.create([o.ownedParameter->first().genType1()/].class); [/if] [if (o.hasStereotype('Update'))] super.update([o.ownedParameter->first().genType1()/].class); [/if] [/if] } [/for] } [/template] [query public hasStereotype( e : uml::Element, value: String) : Boolean = not e.getAppliedStereotypes()->select(e:uml::Stereotype | e.name = value)->isEmpty() /]
bodyWebService.mtl [comment encoding = UTF-8 /] [module bodyWebService('http://www.eclipse.org/uml2/4.0.0/UML')] [import org::eclipse::acceleo::module::proyecto_tx5::main::modules::common/] [import org::eclipse::acceleo::module::proyecto_tx5::common::declaration /] [import org::eclipse::acceleo::module::proyecto_tx5::services::typesServices/] [import org::eclipse::acceleo::module::proyecto_tx5::common::type/] [template public generateBodyWebService(c : Class)] [if (c.hasStereotype('Stateless'))] @Stateless [/if] @WebService public[if (c.isAbstract)] abstract[/if] class [c.name.toUpperFirst()/][for (superC : Class | c.superClass) before(' extends ') separator(',')] [superC.name/][/for][for (interf : Interface | c.getImplementedInterfaces()) before(' implements ') separator(',')] [interf.name/][/for] { private static final long serialVersionUID = 1L; [for (p : Property | c.getAllAttributes())] [if (p.upper = -1 or p.upper > 1)] private List<[p.type.name/]> [p.name/]; [else] private [p.type.name/] [p.name/]; [/if] [/for] [for (p : Property | c.getAllAttributes())] public [if (p.upper = -1 or p.upper > 1)]List<[p.type.name/]>[else][p.type.name/][/if] get[p.name.toUpperFirst()/]() { return this.[p.name/];
219
} public void set[p.name.toUpperFirst()/]([if (p.upper = -1 or p.upper > 1)]List<[p.type.name/]>[else][p.type.name/][/if] p_[p.name/]) { this.[p.name/] = p_[p.name/]; } [/for] [for (p : Property | c.getAssociations().memberEnd)] [if (p.upper = -1 or p.upper > 1)] private List<[p.type.name/]> [p.name/]; [else] private [p.type.name/] [p.name/]; [/if] [/for] [for (o : Operation | c.getOperations())] @WebMethod [o.genMethodPrototype()/] { [if (not o.type.oclIsUndefined())] [if (o.hasStereotype('Search'))] return super.findAll([o.ownedParameter->select(param : Parameter | param.direction = ParameterDirectionKind::return)->first().genType1()/].class); [/if] [else] [if (o.hasStereotype('Create'))] super.create([o.ownedParameter->first().genType1()/].class); [/if] [if (o.hasStereotype('Update'))] super.update([o.ownedParameter->first().genType1()/].class); [/if] [/if] } [/for] } [/template] [query public hasStereotype( e : uml::Element, value: String) : Boolean = not e.getAppliedStereotypes()->select(e:uml::Stereotype | e.name = value)->isEmpty() /]
Paquete: org.eclipse.acceleo.module.proyecto_tx5.common
attributes.mtl [comment encoding = UTF-8 /] [module attributes('http://www.eclipse.org/uml2/3.0.0/UML')] [import org::eclipse::acceleo::module::proyecto_tx5::common::common/] [import org::eclipse::acceleo::module::proyecto_tx5::common::declaration/] [import org::eclipse::acceleo::module::proyecto_tx5::common::type/] [import org::eclipse::acceleo::module::proyecto_tx5::request::request/] [template public genAttributes(anInterface : Interface) ] [for (aProperty : Property | anInterface.ownedAttribute)] [aProperty.genAttributeComment()/] [aProperty.genVisibility()/][aProperty.genFinal()/][aProperty.genStatic()/][aProperty.genType()/] [aProperty.genName()/][aProperty.genDefaultValue()/]; [/for] // [protected ('(user defined attributes)')] // [/protected] [/template]
220
[template public genAttributes(aClass : Class)] [for (aProperty : Property | aClass.ownedAttribute->union(aClass.getOutgoingNavigableOwnedEnd()))] [aProperty.genAttributeComment()/] [aProperty.genVisibility()/][aProperty.genFinal()/][aProperty.genStatic()/][aProperty.genType()/] [aProperty.genName()/][aProperty.genDefaultValue()/]; [/for] // [protected ('(user defined attributes)')] // [/protected] [/template] [template protected genAttributeComment(aProperty : Property)] /** [if (aProperty.ownedComment->size() > 0 and aProperty.ownedComment._body->forAll(b : String | not ''.equalsIgnoreCase(b)))] [for (propertyComment : Comment | aProperty.ownedComment)] * [propertyComment._body/] [/for] [else] * Description of the property [aProperty.genName()/]. [/if] */ [/template]
common.mtl
[comment encoding = UTF-8 /] [module common('http://www.eclipse.org/uml2/3.0.0/UML')] [template public genName(aNamedElement : NamedElement)] [aNamedElement.name.replaceAll(' ', '_')/] [/template] [template public genComment(anElement : Element)] [for (ownedComment : Comment | anElement.ownedComment)] [ownedComment._body/][/for] [/template] [template public genPropertyParent(aProperty : Property)] [/template] [template public genPackagePath(aType : Type)] [aType.packagePath().normalizeName()->reverse()->sep('.')/] [/template] [query public packagePath(aType : Type) : Sequence(Package) = Sequence{aType.getNearestPackage()}->union(aType.getNearestPackage().ancestors()->filter(Package))->select(pack : Package | pack.oclIsTypeOf(Package)) /] [template public genPackagePath(aPackage : Package)] [aPackage.packagePath().normalizeName()->reverse()->sep('.')/] [/template] [query public packagePath(aPackage : Package) : Sequence(Package) = Sequence{aPackage.getNearestPackage()}->union(aPackage.getNearestPackage().ancestors()->filter(Package))->select(pack : Package | pack.oclIsTypeOf(Package)) /] [template public normalizeName(anElement : NamedElement) post(trim())] [if ((anElement.name = 'package') or (anElement.name = 'interface') or (anElement.name = 'class'))]
221
[anElement.name.concat('_')/] [else] [anElement.name/] [/if] [/template]
declaration.mtl
[comment encoding = UTF-8 /] [module declaration('http://www.eclipse.org/uml2/3.0.0/UML')] [import org::eclipse::acceleo::module::proyecto_tx5::common::common/] [import org::eclipse::acceleo::module::proyecto_tx5::common::type/] [import org::eclipse::acceleo::module::proyecto_tx5::request::request/] [template public genMethodPrototype(anOperation : Operation)] [genVisibility()/][genAbstract()/][genFinal()/][genStatic()/][genReturn()/] [genName()/]([genOperationParameters()/]) [/template] [template public genOperationParameters(anOperation : Operation)] [if (anOperation.ownedParameter->select(param : Parameter | not (param.direction = ParameterDirectionKind::return))->size() > 0)] @WebParam(name="[anOperation.genParameterName()/]") [anOperation.ownedParameter->select(param : Parameter | not (param.direction = ParameterDirectionKind::return)).genOperationParameter()->sep(', ')/] [/if] [/template] [template protected genParameterName(anOperation : Operation)] [anOperation.ownedParameter->select(param : Parameter | not (param.direction = ParameterDirectionKind::return)).genOperationParameter1()/] [/template] [template protected genOperationParameter1(aParameter : Parameter)] [aParameter.genName()/] [/template] [template protected genOperationParameter(aParameter : Parameter)] [aParameter.genType()/] [aParameter.genName()/] [/template] [template public genInheritance(aClassifier : Classifier)] [if (aClassifier.general->size() > 0)] extends [for (extendedClassifier : Classifier | aClassifier.general)][extendedClassifier.genName()/][/for][/if] [/template] [template public genInterfaceRealization(aClass : Class)] [if (not aClass.clientDependency->filter(Realization)->isEmpty())] implements [for (namedElement : NamedElement | aClass.getAllInterfaces()) separator(', ')][namedElement.genName()/][/for][/if] [/template] [template public genVisibility(aNamedElement : NamedElement)] [if (not (aNamedElement.visibility = VisibilityKind::_package))][aNamedElement.visibility/] [else]/*package*/ [/if] [/template] [template public genAbstract(aClass : Class)] [if (aClass.isAbstract)]abstract [/if] [/template] [template public genAbstract(anOperation : Operation)] [if (anOperation.isAbstract)]abstract [/if] [/template]
222
[template public genFinal(aRedefinableElement : RedefinableElement)] [if (aRedefinableElement.isLeaf)]final [/if] [/template] [template public genFinal(aProperty : Property)] [if (aProperty.isLeaf)]final [/if] [/template] [template public genStatic(aFeature : Feature)] [if (aFeature.isStatic)]static [/if] [/template] [template public genDefaultValue(aProperty : Property)] = [computeDefault()/] [/template] [template public computeDefault(aProperty : Property) post(trim())] [if (aProperty.upper = 1)] [if (not aProperty.default.oclIsUndefined())] [if (''.equalsIgnoreCase(aProperty.default) or aProperty.default = null)] [if (aProperty.getUserDefaultValue().equalsIgnoreCase(''))][aProperty.default/][else][aProperty.getUserDefaultValue()/][/if] [else] [if ('String'.equalsIgnoreCase(aProperty.type.genName()))][aProperty.default.addQuotes()/][else][aProperty.default/][/if] [/if] [else] [if ('String'.equalsIgnoreCase(aProperty.type.genName()))] ['""'/] [else] [aProperty.getUserDefaultValue()/] [/if] [/if] [else] [if (not aProperty.default.oclIsUndefined())] new [aProperty.genType()/]() [else] new [aProperty.genType()/]() [/if] [/if] [/template] [template public addQuotes(aString : String)] "[aString/]" [/template] [template public getUserDefaultValue(aTypedElement : TypedElement) post(trim())] [if (not getProperty('java.defaultvalue.' + aTypedElement.type.name).size().oclIsUndefined() and (getProperty('java.defaultvalue.' + aTypedElement.type.name).size() > 0) and not ''.equalsIgnoreCase(getProperty('java.defaultvalue.' + aTypedElement.type.name)))] [getProperty('java.defaultvalue.' + aTypedElement.type.name)/] [else] null [/if] [/template]
properties.mtl
[comment encoding = UTF-8 /] [module properties('http://www.eclipse.org/uml2/3.0.0/UML')] [template public getOrderedUniqueCollectionClass(anElement : Element) post(trim())] [anElement.getOrderedUniqueCollectionClassPath().tokenize('.')->last()/] [/template]
223
[template public getOrderedUniqueCollectionClassPath(anElement : Element) post(trim())] java.util.Set [/template] [template public getOrderedUniqueCollectionImplClass(anElement : Element) post(trim())] [anElement.getOrderedUniqueCollectionImplClassPath().tokenize('.')->last()/] [/template] [template public getOrderedUniqueCollectionImplClassPath(anElement : Element) post(trim())] java.util.LinkedHashSet [/template] [template public getOrderedNotUniqueCollectionClass(anElement : Element) post(trim())] [anElement.getOrderedNotUniqueCollectionClassPath().tokenize('.')->last()/] [/template] [template public getOrderedNotUniqueCollectionClassPath(anElement : Element) post(trim())] java.util.List [/template] [template public getOrderedNotUniqueCollectionImplClass(anElement : Element) post(trim())] [anElement.getOrderedNotUniqueCollectionImplClassPath().tokenize('.')->last()/] [/template] [template public getOrderedNotUniqueCollectionImplClassPath(anElement : Element) post(trim())] java.util.ArrayList [/template] [template public getNotOrderedUniqueCollectionClass(anElement : Element) post(trim())] [anElement.getNotOrderedUniqueCollectionClassPath().tokenize('.')->last()/] [/template] [template public getNotOrderedUniqueCollectionClassPath(anElement : Element) post(trim())] java.util.Set [/template] [template public getNotOrderedUniqueCollectionImplClass(anElement : Element) post(trim())] [anElement.getNotOrderedUniqueCollectionImplClassPath().tokenize('.')->last()/] [/template] [template public getNotOrderedUniqueCollectionImplClassPath(anElement : Element) post(trim())] java.util.HashSet [/template] [template public getNotOrderedNotUniqueCollectionClass(anElement : Element) post(trim())] [anElement.getNotOrderedNotUniqueCollectionClassPath().tokenize('.')->last()/] [/template] [template public getNotOrderedNotUniqueCollectionClassPath(anElement : Element) post(trim())] java.util.List [/template] [template public getNotOrderedNotUniqueCollectionImplClass(anElement : Element) post(trim())] [anElement.getNotOrderedNotUniqueCollectionImplClassPath().tokenize('.')->last()/] [/template] [template public getNotOrderedNotUniqueCollectionImplClassPath(anElement : Element) post(trim())] java.util.ArrayList [/template] [query public isArray(anElement : Element) : Boolean = getProperty('tuple.genArrays') = 'true' /]
224
type.mtl
[comment encoding = UTF-8 /] [module type('http://www.eclipse.org/uml2/3.0.0/UML')] [import org::eclipse::acceleo::module::proyecto_tx5::common::properties/] [import org::eclipse::acceleo::module::proyecto_tx5::common::common/] [template public genReturn(anOperation : Operation) post(trim())] [if (anOperation.ownedParameter->select(param : Parameter | param.direction = ParameterDirectionKind::return)-> size() > 0)] [anOperation.ownedParameter->select(param : Parameter | param.direction = ParameterDirectionKind::return)->first().genType()/] [else] void [/if] [/template] [template public genType(aProperty : Property) post(trim())] [if (aProperty.upper = 1)] [aProperty.genTypeName()/] [elseif (aProperty.isArray())] [aProperty.genTypeName()/]['['/][']'/] [else] [aProperty.genCollectionType()/]<[aProperty.genTypeName()/]> [/if] [/template] [template public genType(aParameter : Parameter) post(trim())] [if (aParameter.upper = 1)] [aParameter.genTypeName()/] [elseif (aParameter.isArray())] [aParameter.genTypeName()/]['['/][']'/] [else] List<[aParameter.genTypeName()/]> [/if] [/template] [template public genType1(aParameter : Parameter) post(trim())] [if (aParameter.upper = 1)] [aParameter.genTypeName()/] [elseif (aParameter.isArray())] [aParameter.genTypeName()/]['['/][']'/] [else] [aParameter.genTypeName()/] [/if] [/template] [template protected genTypeName(aTypedElement : TypedElement) post(trim())] [if (aTypedElement.type = null)] Object [elseif (not getProperty('java.typeconversion.' + aTypedElement.type.name).oclIsUndefined() and (getProperty('java.typeconversion.' + aTypedElement.type.name).size() > 0))] [getProperty('java.typeconversion.' + aTypedElement.type.name).tokenize('.')->last()/] [elseif (type.name = 'UnlimitedNatural')] Integer [else] [aTypedElement.type.genName().tokenize('.')->last()/] [/if] [/template] [template public genInitValue(aProperty : Property)] [if ((aProperty.upper <> 1 and not aProperty.isArray()))] = new [aProperty.genCollectionImplType()/]<[aProperty.genTypeName()/]>()[/if] [/template] [template protected genCollectionType(aMultiplicityElement : MultiplicityElement) post(trim())] [if (not aMultiplicityElement.isOrdered.oclIsUndefined() and aMultiplicityElement.isOrdered)] [if (aMultiplicityElement.isUnique)]
225
[aMultiplicityElement.getOrderedUniqueCollectionClass()/] [else] [aMultiplicityElement.getOrderedNotUniqueCollectionClass()/] [/if] [else] [if (aMultiplicityElement.isUnique)] [aMultiplicityElement.getNotOrderedUniqueCollectionClass()/] [else] [aMultiplicityElement.getNotOrderedNotUniqueCollectionClass()/] [/if] [/if] [/template] [template protected genCollectionImplType(aMultiplicityElement : MultiplicityElement) post(trim())] [if (not aMultiplicityElement.isOrdered.oclIsUndefined() and aMultiplicityElement.isOrdered)] [if (aMultiplicityElement.isUnique)] [aMultiplicityElement.getOrderedUniqueCollectionImplClass()/] [else] [aMultiplicityElement.getOrderedNotUniqueCollectionImplClass()/] [/if] [else] [if (aMultiplicityElement.isUnique)] [aMultiplicityElement.getNotOrderedUniqueCollectionImplClass()/] [else] [aMultiplicityElement.getNotOrderedNotUniqueCollectionImplClass()/] [/if] [/if] [/template] [query protected isJavaPrimitive(aType : Type) : Boolean = aType.name.equalsIgnoreCase('int') or aType.name.equalsIgnoreCase('Integer') or aType.name.equalsIgnoreCase('float') or aType.name.equalsIgnoreCase('boolean') or aType.name.equalsIgnoreCase('byte') or aType.name.equalsIgnoreCase('long') or aType.name.equalsIgnoreCase('short') or aType.name.equalsIgnoreCase('char') or aType.name.equalsIgnoreCase('Character') or aType.name.equalsIgnoreCase('void') or aType.name.equalsIgnoreCase('String') or aType.name.equalsIgnoreCase('double') /]
Paquete: org.eclipse.acceleo.module.proyecto_tx5.request
request.mtl
[comment encoding = UTF-8 /] [module request('http://www.eclipse.org/uml2/3.0.0/UML')] [** * Returns all the content of the model. Since this is a query, the result is stored in cache. * @param aModel The UML model. */] [query public eAllContentsQuery(aModel : Model) : Sequence(OclAny) = aModel.eAllContents() /] [** * Returns all the interface of a given class. * @param aClass The class. */] [query public getAllInterfaces(aClass : Class) : Bag(NamedElement) = aClass.clientDependency->filter(Realization).supplier /] [**
226
* Returns all the operations of the superclasses of a given class. * @param aClass The class. */] [query public getAllSuperClassOperations(aClass : Class) : Sequence(Operation) = aClass.general->filter(Class).ownedOperation->asSequence() /] [** * Returns all the operations of the interfaces implemented by the given class. * @param aClass The class. */] [query public getAllInterfaceOperations(aClass : Class) : Sequence(Operation) = aClass.getAllInterfaces()->filter(Interface).ownedOperation->asSequence() /] [** * Returns all the properties corresponding to navigable ends of the outgoing * associations for the given class. * @param aClass The class. */] [query public getOutgoingNavigableOwnedEnd(aClass : Class) : Set(Property) = getSelfAssociationsNavigableOwnedEnd(aClass) ->union(getOtherAssociationsNavigableOwnedEnd(aClass))->asOrderedSet() /] [query private getSelfAssociationsNavigableOwnedEnd(aClass : Class) : Set(Property) = aClass.getAssociations()->select(ownedEnd.type->asSet()->size() = 1).navigableOwnedEnd->asOrderedSet() /] [query private getOtherAssociationsNavigableOwnedEnd(aClass : Class) : Set(Property) = aClass.getAssociations()->select(navigableOwnedEnd->select(type <> aClass)->size() = 1).navigableOwnedEnd->select(type <> aClass)->asOrderedSet() /]
Paquete: org.eclipse.acceleo.module.proyecto_tx5.services
StereotypesServices.mtl [module stereotypesServices('http://www.eclipse.org/uml2/4.0.0/UML')] [query public attributecardinality(attribute:Property) : String = invoke('org.eclipse.acceleo.modules.proyecto_tx5.services.StereotypesServices', 'returncardinality(org.eclipse.uml2.uml.Property)',Sequence{attribute}) /]
TypesServices.mtl
[module typesServices('http://www.eclipse.org/uml2/4.0.0/UML')] [query public reqReturnTypeName(anOperation : Operation) : String = invoke('org.eclipse.acceleo.module.proyecto_tx5.servicios.TypesServices', 'returnTypeName(org.eclipse.uml2.uml.Operation)', Sequence{anOperation}) /] [query public reqTypeName(aTypedElement : TypedElement) : String = invoke('org.eclipse.acceleo.module.proyecto_tx5.servicios.TypesServices', 'typeName(org.eclipse.uml2.uml.TypedElement)', Sequence{aTypedElement}) /] [query public reqDefaultValue(aTypedElement : TypedElement) : String = invoke('org.eclipse.acceleo.module.proyecto_tx5.servicios.TypesServices', 'defaultValue(org.eclipse.uml2.uml.TypedElement)', Sequence{aTypedElement}) /]
StereotypesServices.java
227
import java.util.Iterator; import org.eclipse.emf.common.util.EList; import org.eclipse.uml2.uml.Element; import org.eclipse.uml2.uml.Property; import org.eclipse.uml2.uml.Stereotype; public class StereotypesServices { public String returnCardinalidad(Property propiedad) { String valor_type="cardinalidad"; Stereotype stereotype = getStereotype(propiedad, "Association"); valor_type=(String) propiedad.getValue(stereotype, "type"); return "@"+valor_type; } public static Stereotype getStereotype(Element element, String stereotypeName) { EList stereotypes = element.getAppliedStereotypes(); for (Iterator i = stereotypes.iterator(); i.hasNext();) { Stereotype stereotype = (Stereotype) i.next(); if (stereotype.getName().equals(stereotypeName)) { return stereotype; } } return null; } }
UmlServices.java
package org.eclipse.acceleo.module.proyecto_tx5.servicios; import java.util.Collection; import java.util.Iterator; import java.util.Vector; import org.eclipse.emf.common.util.EList; import org.eclipse.uml2.uml.Association; import org.eclipse.uml2.uml.Class; import org.eclipse.uml2.uml.Dependency; import org.eclipse.uml2.uml.Element; import org.eclipse.uml2.uml.NamedElement; import org.eclipse.uml2.uml.Operation; import org.eclipse.uml2.uml.Parameter; import org.eclipse.uml2.uml.ParameterDirectionKind; import org.eclipse.uml2.uml.Property; import org.eclipse.uml2.uml.Stereotype; public class UmlServices { /** * Get the topmost Class * * @param subClass * @return */ public Class getSuperClassOfHierarchy(Class subClass) { Class result = subClass; while (!result.getGenerals().isEmpty()) { result = (Class) result.getGenerals().get(0); } return result; }
228
/** * List all stereotypes owned by the Element * * @param element * @param stereotypeName * @return */ public static Stereotype getStereotype(Element element, String stereotypeName) { EList stereotypes = element.getAppliedStereotypes(); for (Iterator i = stereotypes.iterator(); i.hasNext();) { Stereotype stereotype = (Stereotype) i.next(); if (stereotype.getName().equals(stereotypeName)) { return stereotype; } } return null; } public static String getStereotypes(Element element) { EList stereotypes = element.getAppliedStereotypes(); String st = ""; for (Iterator i = stereotypes.iterator(); i.hasNext();) { Stereotype stereotype = (Stereotype) i.next(); st = st + stereotype + ", "; } return st; } /** * Does the current element have the stereotype ? * * @param element * @param stereotypeName * @return Boolean */ public static boolean hasStereotype(Element element, String stereotypeName) { Stereotype stereotype = getStereotype(element, stereotypeName); return (stereotype != null); } /** * Get the stereotype value from the element * * @param element * element that has the stereotype * @param stereotypeName * name of the stereotype * @param propertyName * name of the stereotype attribute to get the value from * @return */ public Object getValue(Element element, String stereotypeName, String propertyName) { Stereotype stereotype = getStereotype(element, stereotypeName); return element.getValue(stereotype, propertyName); } /** * Get whether the stereotype has a value or not. * * @param element * element that has the stereotype * @param stereotypeName * name of the stereotype * @param propertyName * name of the stereotype attribute to get the value from * @return
229
*/ public Boolean hasValue(Element element, String stereotypeName, String propertyName) { Stereotype stereotype = getStereotype(element, stereotypeName); return element.hasValue(stereotype, propertyName); } /** * Give to opposite attribute of an association. * * @param association * @param element * @return */ public Property oppositeAttributeOf(Association association, Class element) { EList list = association.getMemberEnds(); try { Property prop; Iterator iter = list.iterator(); while (iter.hasNext()) { prop = (Property) iter.next(); if (!prop.getType().equals(element)) return prop; } return null; } catch (Exception e) { return null; } } /** * Return the opposite Class in the current association from the current * Class * * @param association * current association * @param element * current Class of the association * @return Class Other class of the asoication */ public Class oppositeClassOf(Association association, Class element) { EList list = association.getMemberEnds(); Property prop; Iterator iter = list.iterator(); while (iter.hasNext()) { prop = (Property) iter.next(); try { if (!prop.getType().equals(element)) return (Class) prop.getType(); } catch (Exception e) { return null; } } return null; } /** * Return return parameter * * @param op * @return */ public Parameter returnResult(Operation op) {
230
return op.getReturnResult(); } /** * Return the list of class' associations * * @param element * @return */ public Collection getAssociations(Class element) { return element.getAssociations(); } /** * Is the property of the association navigable ? * * @param prop * the property * @return Boolean */ public boolean isNavigable(Property prop) { if (prop.getAssociation() != null) return prop.getAssociation().getNavigableOwnedEnds().contains(prop); else return true; } /** * is the association a directionnal association between 2 "Entity" ? * * @param association * @return Boolean */ public Boolean hasFkAssociation(Association association) { EList list = association.getMemberEnds(); Iterator iter = list.iterator(); Boolean entities = Boolean.TRUE; Property prop; // For each property of the association while (iter.hasNext()) { prop = (Property) iter.next(); try { if(!hasStereotype((Class)prop.getType(), "Entity")) entities = Boolean.FALSE; } catch (Exception e) { entities = Boolean.FALSE; } } return entities; } /** * Get the source entity of the association * * @param association * @return the non pointed entity of a directionnal association */ public Class fkAssociationEntity(Association association) { EList list = association.getMemberEnds(); Iterator iter = list.iterator(); Property prop; // Both classes are entities, now we have to find the navigation
231
if (hasFkAssociation(association).booleanValue()) { iter = list.iterator(); prop = (Property) iter.next(); if (prop.isNavigable()) { prop = (Property) iter.next(); } return (Class) prop.getType(); } else { return null; } } /** * * @param association * @return the pointed entity of a directionnal association */ public Property fkAssociationProp(Association association) { EList list = association.getMemberEnds(); Iterator iter = list.iterator(); Property prop; // Both classes are entities, now we have to find the navigation if (hasFkAssociation(association).booleanValue()) { iter = list.iterator(); prop = (Property) iter.next(); if (!prop.isNavigable()) { prop = (Property) iter.next(); } return prop; } else { return null; } } /** * Return true if "element" is associated with a Class having the * "stereotype" stereotype. * * @param element * @param stereotype * @return */ public boolean hasAssociationWithClassStereotyped(Class element, String stereotype) { boolean trouve = false; // list of associations Collection associations = getAssociations(element); // browse the associations and look if is has "stereotype" Iterator ai = associations.iterator(); Association a; Class opposite; while (!trouve && ai.hasNext()) { a = (Association) ai.next(); opposite = oppositeClassOf(a, element); if (opposite != null) if (hasStereotype(opposite, stereotype)) trouve = true; } return trouve; }
232
/** * Return the suppliers from whom depends element. * * @param element * @return */ public Collection getDependenciesSuppliers(NamedElement element) { // list of associations Collection cc = new Vector(); EList cd = element.getClientDependencies(); // browse the dependencies Iterator id = cd.iterator(); Dependency d; while (id.hasNext()) { d = (Dependency) id.next(); cc.addAll((Collection) d.getSuppliers()); } return cc; } /** * Return the suppliers from whom depends element. * * @param element * @return */ public Collection getClientDependencies(NamedElement element) { return element.getClientDependencies(); } }
233
8. Referencias
[1] Object Management Group. “Business Process Model and Notation (BPMN)”. OMG,
(2011). http://www.omg.org/spec/BPMN/2.0/PDF/. Ultimo Acceso 15/11/2011.
[2] Object Management Group. http://www.omg.org/. Último acceso 20/03/2015.
[3] MDA. http://www.omg.org/mda/. Último acceso 15/01/2015.
[4] Object Management Group. “Meta Object Facility (MOF) 2.0
Query/View/Transformation Specification”. 2008.
http://www.omg.org/spec/QVT/1.0/PDF. Ultimo Acceso 25/07/2014.
[5]Unified Modeling Language(UML).version 2.4 OMG,
http://www.omg.org/spec/UML/2.4.1/. Último acceso 20/03/2015.
[6] Enterprise JavaBeans 3.1. Java Community Process. http://jcp.org/en/jsr/detail?id=318.
Último acceso 14/10/2012.
[7] Java Persistence 2.0.Java Community Process.
http://jcp.org/en/jsr/detail?id=317http://docs.oracle.com/javaee/6/tutorial/doc/. Último
acceso 14/10/2012.
[8] The Java EE 6 Tutorial. Oracle.2010. http://docs.oracle.com/javaee/6/tutorial/doc/.
Último acceso 01/06/2014.
[9] Acceleo. http://www.acceleo.org/pages/home/en. Último acceso 14/10/2014.
[10] MOFM2T. http://www.omg.org/spec/MOFM2T/1.0/PDF/. Último acceso 14/10/2014.
[11] C. Wohlin, P. Runeson, M. Höst, M. C. Ohlsson, B. Regnell and A. Wesslén,
"Experimentation in Software Engineering", Springer, ISBN 978-3-642-29043-5, 2012.
[12] Marcos, E., “Investigación en Ingeniería del Software vs. Desarrollo”, Grupo
KYBELE. Universidad Rey Juan Carlos.
http://gidis.inf.pucp.edu.pe/recursos/InvIngSWvsDS.pdf
234
[13] Delgado A, Ruiz. F, Garcia I, Piattini M, Un experimento para validar
transformaciones QVT para la generación de modelos de servicios en SoaML desde
modelos de procesos de negocio en BPMN2. Sistides 2012.XVII Jornadas de Ingeniería del
Software y Bases de Datos.
[14] Anneke Kleppe. Jos Warmer. Wim Bast. “MDA Explained: The Model Driven
Architecture: Practice and Promise”. Addison Wesley. 2003.
[15] ATL. http://www.eclipse.org/atl/. Último acceso 12/10/2014.
[16] MediniQVT. http://projects.ikv.de/qvt. Último acceso 01/12/2014.
[17] Object Management Group. “Object Constraint Language”.Version 2. Object
Management Group. 2006. http://www.omg.org/spec/OCL/2.0/PDF/. Ultimo Acceso
21/09/2014.
[18] Fuentes-Fernández, L., Vallecillo, A.: An Introduction to UML Profiles. In: The
European Journal for the Informatics Professional (UPGRADE), vol. 5 nº 2, 5–13 (2004)
[19] Bruce Silver.Robert Shapiro, Stephen A. White PhD., Nathaniel Palmer, Michael zur
Muehlen PhD., Thomas Allweyer, Denis Gagné. “BPMN 2.0 Handbook”.Layna Fischer.
ISBN: 978-0-9819870-7-1
[20] Jakob Freund. Bernd Rucker. Bernhard Hitpass.“BPMN 2.0 Manual de Referencia y
Guía Práctica”. BPMCenter. Primera edición. 2011.
[21] Object Management Group. “XML Metadata Interchange Specification”. Version
2.0.1.2006. http://www.omg.org/spec/XMI/ISO/19503/PDF/. Último Acceso 15/11/2011.
[22] JSR-000316 Java Platform, Enterprise Edition 6 Specification. Version 6.0. SUN
MICROSYSTEMS, INC.2009
[23] Uwe Rozanski.“Enterprise JavaBeans 3.0 con Eclipse y JBoss”. Marcombo.2009.
ISBN:978-84-267-1471-8
[24] GlassFish Server. http://glassfish.java.net/es/. Ultimo Acceso 20/11/2013.
[25] JBoss Application Server. http://www.jboss.org/jbossas/. Ultimo Acceso 20/11/2013.
[26] Sriganesh Patel, Brose Gerald, Silverman Micah. “Mastering Enterprise JavaBeans
3.0”. Wiley Publishing, Inc..2006.
[27] MediniQVT. http://projects.ikv.de/qvt/. Último acceso 21/02/2015.
235
[28] Davis, R., Brabänder, E. “ARIS Design Platform: Getting Started with BPM”.
Springer, Londres.2007.
[29] Miles, R., Hamilton, K. “Learning UML 2.0”. O’Reilly, Sebastopol, CA.2006.
[30] Tscheschner, W.“Transformation from EPC to BPMN”. Oryx Research, Potsdam,
Germany, 2010.
[31] Rodríguez, A., Fernández-Medina, E. y Piattini, M.; Towards Obtaining Analysis-
Level Class and Use Case Diagrams from Business Process Models, 4º International
Workshop on Foundations and Practices of UML (FP-UML), en conjunto con la 27th
International Conference on Conceptual Modeling (ER). Barcelona, España. Lecture Notes
in Computer Science Volumen 5232, (2008). pp:103-112
[32] Ernesto Suarez, Medardo Delgado, Elizabeth Vidal. “Transformation of a Process
Business Model to Domain Model”. Proceedings of the World Congress on Engineering
Vol I. 2008.
[33] Delgado A,García-Rodríguez de Guzman I, Ruiz, Francisco, Piattini, M. “From
BPMN business process models to SoaML service models: A transformation-driven
approach”. Software Technology and Engineering (ICSTE), V1-p. 314 - V1-319,2010.
[34] Web Services Business Process Execution Language Version 2.0. http://docs.oasis-
open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.pdf. Último acceso 10/03/2014.
[35] C. Ouyang W. M.P. van der Aalst, M.Dumas, et al, "Translating BPMN to BPEL",
BPM Center Report BPM-06-02, BPMcenter.org 2006.
[36] Smith,H.,Fingar,P.,Business Process Management: The third wave, Meghan-Kieffer,
(2003).
[37] Krafzig, D., et.al, Enterprise SOA, SOA: Best Practices, Prentice Hall, (2005).
[38] Activiti. www.activiti.org. Último acceso 20/05/2015.
[39] JBPM.http://www.jboss.org/jbpm/. Último acceso 20/05/2015.
[40] BonitaSoft. http://www.bonitasoft.com/. Último acceso 20/05/2015.
[41] Kherraf S, Lefebvre E, Suryn W. “Transformation from CIM to PIM Using Patterns
and Archetypes”, Software Engineering, 2008. ASWEC 2008. Pp: 338 – 346.
[42] P. Coad, E. Lefebvre, and J. De Luca, Java Modeling In Color With UML: Enterprise
Components and Process Prentice Hall , 1999.
[43] SoaML. http://www.omg.org/spec/SoaML/1.0.1/. Último acceso 10/12/2012.
236
[44] Krafzig, D., et.al, Enterprise SOA, SOA: Best Practices, Prentice Hall, (2005).
[45] Brian Elvesæter , Dima Panfilenko , Sven Jacobi , Christian Hahn. “Aligning business
and IT models in service-oriented architectures using BPMN and SoaML”, Proceedings of
the First International Workshop on Model-Driven Interoperability, p.61-68, October 03-
05, 2010, Oslo, Norway.
[46] A. Sturm, “Enabling off-line business process analysis: A transformation based
approach,” in BPMDS, 2008
[47] Cruz E, Machado R, Santos M. “From Business Process Modeling to Data Model: A
systematic approach”, Quality of Information and Communications Technology
(QUATIC), Pp: 205 – 210. 2012
[48] Daissaoui A, Casablanca, Morocco “Applying the MDA approach for the automatic
generation of an MVC2 web application”, Research Challenges in Information Science
(RCIS), 2010 . Pp. 681 – 688.
[49] Kun Ma,Bo Yang. "A Hybrid Model Transformation Approach Based On J2EE
Platform", Second International Workshop on Education Technology and Computer
Science. 2010.
[50] Esbai R, Erramdani M,Mbarki S, Arrassen I.” Model-Driven transformation with
approach by modeling: From UML to N-tiers Web Model”. IJCSI International Journal of
Computer Science Issues, Vol. 8, Issue 4, No 2, July 2011.
[51] T. Rademakers.”Activiti in Action Executable Business Processes in BPMN 2.0”,
Manning Publications Co. 2012.
[52] Dijkman, R.M and Joosten, Stef (2002) “Deriving Use Case Diagrams from Business
Process Models”. CTIT Technical Reports Series, 08 (02). ISSN 1381-3625
[53] Eclipse Modeling Framework. https://eclipse.org/modeling/emf/. Último acceso
20/05/2015.
[54] The GeneSEZ JPA UML Profile.
http://documentation.genesez.org/javaee/de.genesez.uml.profile.jpa.html/.
[55] XML Schema. http://www.w3.org/TR/xmlschema-1. Ultimo Acceso 20/11/2014.
[56] SchemaXML Path Language (XPath). http://www.w3.org/TR/xpath. Ultimo Acceso
20/11/2014.
[57] Camunda Modeler. http://camunda.org/bpmn/tool/. Ultimo Acceso 10/11/2014.
237
[58] Martinez C.A., Zorzan, F. , Riesco D. “Transformación de modelos ejecutables bpmn
2 a la tecnología enterprise java beans 3.1-java api persistence 2”. Jornadas de Ingeniería
CODINOA 2011.
[59] Debnath N. , Martinez C.A. , Zorzan F. , Riesco D., Montejano G. “Transformation of
business process models BPMN 2.0 into components of the Java business platform”.
Industrial Informatics (INDIN), 2012 10th IEEE International Conference.
[60] BPMN 2.0 Best Practices. http://camunda.org/bpmn/examples/. Último acceso
10/03/2015.
[61] Interaction Flow Modeling Language. http://www.omg.org/spec/IFML/1.0/PDF/.
Último acceso 20/03/2015.
[62] UML Infrastructure Specification, v2.3. OMG Unified Modeling Language TM (OMG
UML). http://www.omg.org/spec/UML/2.3/. Último acceso 23/03/2014.
[63] UML Superstructure Specification, v2.4.1. OMG Unified Modeling Language TM
(OMG UML). http://www.omg.org/spec/UML/2.4.1/. Último acceso 17/04/2014.
[64] Common Object Request Broker Architecture. http://www.corba.org/. Último acceso
17/03/2014.
238
9. Siglas
A
API Application Programming Interface
ATL ATL Transformation Language
B
BAM Business Activity Monitoring
BPM Business Process Management
BPMI Business Process Management Initiative
BPMN Business Process Model Notation
BPMS Business Process Management Suite
BRMS Business Rules Management System
C
CIM Computation Independent Model
CORBA Common Object Request Broker Architecture
CRM Customer Relationship Management
CRUD Create, Read, Update and Delete
D
DAO Data Access Object
E
EAR Enterprise Archive
EJB Enterprise Java Bean
EMF Eclipse Modeling Framework
EMOF Essential Meta Object Facility
EPL Eclipse Public License
ERP Enterprise Resource Planning
ESB Enterprise Service Bus
239
H
HTTP HyperText Transfer Protocol
I
ISO International Standarization Organization
J
JAR Java ARchive
Java EE Java Platform, Enterprise Edition
JAX-WS Java API for XML-Web Services
JBPM JBoss Business Process Management
JCP Java Community Proces
JMS Java Message Service
JNI Java Native Interface
JPA Java Persistence API
JSR Java Specification Requests
K
KPI Key Performance Indicators
M
MDA Model Driven Architecture
MDB Message-Driven Bean
MOF Meta Object Facility
MOFM2T Meta Object Facility Model to Text Transformation Language
M2T Model to Text Transformation Language
MTL Model to Text Transformation Language
MVC Model-View-Controller
O
240
OCL Object Constraint Language
OMG Object Management Group
P
PIM Plataform Independent Model
POJO Plain Old Java Object
PSM Plataform Specific Model
Q
QVT Query View Transformation
R
REST Representational State Transfer
RMI Java Remote Method Invocation
S
SOAP Simple Object Access Protocol
U
UDDI Universal Description, Discovery and Integration
UML Unified Modeling Language
W
WAR Web Application Archive
WWW World Wide Web
W3C World Wide Web Consortium
WSDL Web Services Description Language
X
XMI XML Metadata Interchange
XML eXtensible Markup Language
XSLT eXtensible Stylesheet Language Transformations
241
XSD XML Schema Definition