Transformación de Modelos de Procesos del Negocio … · II Resumen La mejora continua en las...

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


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

http://es.wikipedia.org/wiki/Metodolog%C3%ADa

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.

http://es.wikipedia.org/wiki/Stakeholder

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.


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.


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


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


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


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.


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.


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.


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:


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.


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.


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.


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.


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.

http://www.jcp.org/jsr/detail

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

http://www.jcp.org/jsr/detail

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.

http://es.wikipedia.org/wiki/Framework

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

http://es.wikipedia.org/wiki/WSDL

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

http://es.wikipedia.org/wiki/UDDI

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.

http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=6511062


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.

http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=5507266


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


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.


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


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.


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


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


Operación dentro de un elemento

Class de UML, dentro del paquete

business.

uml::Operation. Anotada

con WebMethod.

85


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


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.


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


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


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


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


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.


91

bpmn2::Lane El elemento Lane de Bpmn 2


Class de UML dentro del

Package Business.


ass. La clase es anotada con

<<Entity>>.


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


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.


bpmn2::Participant El elemento Participant de

Bpmn 2 se transforma en un

elemento Class de UML

dentro del Package Entities.


ass

93


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.


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.


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


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.


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.


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.


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


A.2 Modelo UML 2

Se utiliza como origen el modelo UML2 con perfil JavaEE generado por la transformación

anterior.


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.


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.


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


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


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

http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin=p_Authors:.QT.Martinez,%20C.A..QT.&searchWithin=p_Author_Ids:38482884800&newsearch=true

http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin=p_Authors:.QT.Zorzan,%20F..QT.&searchWithin=p_Author_Ids:38476666600&newsearch=true

http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin=p_Authors:.QT.Riesco,%20D..QT.&searchWithin=p_Author_Ids:37313081600&newsearch=true

http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin=p_Authors:.QT.Debnath,%20N..QT.&searchWithin=p_Author_Ids:37312280300&newsearch=true




http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin=p_Authors:.QT.Montejano,%20G..QT.&searchWithin=p_Author_Ids:37313082200&newsearch=true

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


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.

http://www.w3.org/2001/XMLSchema

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


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


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


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


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


[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

http://www.omg.org/spec/QVT/1.0/PDF.%20Ultimo%20Acceso%2025/07/2014

http://www.omg.org/spec/UML/2.4.1/

http://jcp.org/en/jsr/detail?id=318



http://docs.oracle.com/javaee/6/tutorial/doc/

http://www.springer.com/computer/swe/book/978-3-642-29043-5

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.

http://www.informit.com/safari/author_bio.asp@ISBN=032119442X



http://projects.ikv.de/qvt.%20Último%20acceso%2001/12/2014

http://www.omg.org/spec/OCL/2.0/PDF/

http://www.omg.org/spec/XMI/ISO/19503/PDF/

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.


http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.pdf

http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.pdf

http://www.bonitasoft.com/


http://www.omg.org/spec/SoaML/1.0.1/

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.

http://dl.acm.org/citation.cfm?id=1866281&CFID=349334371&CFTOKEN=35828499








http://documentation.genesez.org/javaee/de.genesez.uml.profile.jpa.html/

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


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




http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin=p_Authors:.QT.Debnath,%20N..QT.&searchWithin=p_Author_Ids:37312280300&newsearch=true




http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin=p_Authors:.QT.Montejano,%20G..QT.&searchWithin=p_Author_Ids:37313082200&newsearch=true

http://camunda.org/bpmn/examples/

http://www.omg.org/spec/IFML/1.0/PDF/

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

Transformación de Modelos de Procesos del Negocio … · II Resumen La mejora continua en las...

Documents

Transcript of Transformación de Modelos de Procesos del Negocio … · II Resumen La mejora continua en las...