Transformación de Modelos de Procesos del Negocio BPMN 2.0 a Componentes de la Capa del Negocio Java

Transcripción

1 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

2 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!!! I

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

4 Índice 1. INTRODUCCIÓN MOTIVACIÓN OBJETIVOS DE LA TESIS METODOLOGÍA DE TRABAJO ESTRUCTURA DE LA TESIS CONCEPTOS BÁSICOS ARQUITECTURA DIRIGIDA POR MODELOS METAMODELOS Y ARQUITECTURA MOF Nivel M3 (Meta-metamodelo) Nivel M2 (Metamodelo) Nivel M1 (Modelo) Nivel M0 (Instancias) TRANSFORMACIONES CON QUERY VIEW TRANSFORMATION (QVT) Transformaciones QVT-QVT/Relations QVT Relations Herramienta Medini-QVT Herramienta Acceleo Perfiles UML BPMN 2 (BUSINESS PROCESS MODELING NOTATION 2) Gestión de Procesos del Negocio (Business Process Management-BPM) BPMS BPMN Framework Notación de BPMN Diagrama de Colaboración Modelado de Diagramas BPMN 2.0 Ejecutables Intercambio de Modelos COMPONENTES DEL NEGOCIO JAVA EE Introducción Enterprise Java Beans Web Services Java Persistent API (JPA) ESTADO DEL ARTE MDA Y PROCESOS DEL NEGOCIO Arquitectura Dirigida por Modelos Modelado de Procesos del Negocio y BPMN BPM y BPMS TRABAJOS RELACIONADOS Criterios de Análisis de las propuestas Transformaciones de Procesos del Negocio a UML y SoaML Análisis de Transformaciones de Procesos del Negocio a UML y SoaML Transformaciones de PIM a PSM y de PSM a código Análisis de Transformaciones de PIM a PSM y de PSM a código CONCLUSIONES TRANSFORMACIÓN DE MODELOS DE PROCESOS DEL NEGOCIO BPMN 2.0 A COMPONENTES DE LA CAPA DEL NEGOCIO JAVA EE COMPONENTES DE LA TRANSFORMACIÓN III

5 4.1.1 Relación de la Propuesta con Otros Componentes Vinculados a la Arquitectura de una Aplicación SOA Definición de las Transformaciones con QVT TRANSFORMACIÓN DE BPMN 2 A UML Ejemplo Genérico de Transformación de BPMN 2 a UML Perfil Independiente de la Tecnología Generación de modelo UML 2 con paquetes: entities y business Transformación de un elemento Process de BPMN 2.0 a un elemento Class UML Transformación de un elemento Lane de BPMN 2.0 a un elemento Class UML Transformación de un elemento ServiceTask de BPMN 2.0 a un elemento Operation de una Clase UML Transformación de un elemento DataStore de BPMN 2.0 a elementos Operation de una Clase UML Transformación de un modelo BPMN 2.0 a Elementos Generales UML Transformación de un elemento DataStore a elementos UML Transformación de un elemento Lane de BPMN 2.0 a un elemento Class UML Transformación de un elemento Participant de BPMN 2.0 a un elemento Class UML TRANSFORMACIÓN DE UN MODELO UML2 CON PERFIL INDEPENDIENTE DE LA TECNOLOGÍA A UN MODELO UML2 CON PERFIL EJB3.1-JPA Ejemplo de Transformación de UML2 con perfil independiente de la tecnología a UML2 con perfil Ejb3.1-JPA Perfil Java EE Perfil JPA Transformaciones del paquete Business Transformaciones del paquete Entities TRANSFORMACIÓN DE MODELO UML2 CON PERFIL EJB3.1-JPA2 A CÓDIGO FUENTE JAVAEE Ejemplo de UML2 con perfil Ejb3.1-JPA2 a Código Fuente JavaEE Estructura del Proyecto Acceleo Transformaciones del Paquete Business Transformación del Paquete Entities CONCLUSIONES APLICACIÓN DEL MÉTODO DE TRABAJO Y CASOS DE ESTUDIO APLICACIÓN DEL MÉTODO DE TRABAJO Método de Trabajo Aplicado a la Transformación de BPMN 2 a UML 2 con perfil independiente de la plataforma 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-JPA Método de Trabajo Aplicado a la transformación de un modelo UML2 con perfil Ejb3.1-JPA2 a Código Fuente JavaEE VERSIONES DESARROLLADAS DE LAS TRANSFORMACIONES CASOS DE ESTUDIO DE LABORATORIO Y REALES CASO DE ESTUDIO DEL SISTEMA DE MANTENIMIENTO Planteo del Problema Modelo del Proceso Técnico BPMN Transformación de BPMN 2 a UML Transformación de UML2 a UML2 con perfil Ejb3.1-JPA Transformacion con Acceleo CONCLUSIONES CONCLUSIONES RESULTADOS OBTENIDOS PRINCIPALES APORTES Y PUBLICACIONES LÍNEAS DE TRABAJO FUTURAS CONCLUSIONES FINALES IV

6 7. ANEXOS ANEXO1. METAMODELO BPMN BPMN Core Structure Colaboración (Collaboration) Flujo de Mensaje (Message Flow) Proceso (Process) Actividades (Activities) Modelado de Datos Carril (Lane) ANEXO 2. METAMODELO UML Especificación UML Infraestructura (Infrastructure) Superstructure Perfiles (Profiles) ANEXO 3. CASO DE ESTUDIO DE LA RAC Planteo del Problema Modelo del Proceso Técnico BPMN Transformación de BPMN 2 a UML Transformación de UML2 a UML2 con perfil Ejb3.1-JPA Transformación con Acceleo Conclusiones ANEXO 4. CÓDIGO FUENTE QVT RELATIONS: TRANSFORMACIÓN DE MODELO BPMN 2.0 A MODELO UML2 CON PERFIL INDEPENDIENTE DE LA TECNOLOGÍA ANEXO 5. CÓDIGO FUENTE QVT RELATIONS: TRANSFORMACIÓN DE UML2 CON PERFIL INDEPENDIENTE DE LA TECNOLOGÍA A UML2 CON PERFIL EJB3.1-JPA ANEXO 6. CÓDIGO FUENTE DE ACCELEO: TRANSFORMACIÓN DE UML2 CON PERFIL EJB3.1-JPA2 A CÓDIGO FUENTE JAVAEE REFERENCIAS SIGLAS V

7 Í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 Figura 2.3 Ejemplo de consulta OCL Figura 2.4 Relación entre los metamodelos QVT Figura 2.5 Declaración de una transformación en QVT Figura 2.6 Ejemplo de dominios Figura 2.7 Ejemplo de clausulas checkonly y enforce Figura 2.8 Ejemplo de relación con las claúsulas when y where Figura 2.9 Ejemplo de coincidencia de patrones (pattern matching) Figura 2.10 Ejemplo de Clave Figura 2.11 Declaración de módulo Figura 2.12 Ejemplo de módulo Figura 2.13 Declaración de import Figura 2.14 Ejemplo de import Figura 2.15 Declaración de plantilla Figura 2.16 Ejemplo de plantilla Figura 2.17 Declaración de consulta Figura 2.18 Ejemplo de consulta Figura 2.19 Ejemplo de Perfil Figura 2.20 El ciclo de BPM Figura 2.21 El ciclo de BPM Figura 2.22 Niveles de Abstracción del BPMN Framework Figura 2.23 Tipos básicos de eventos Figura 2.24 Algunos tipos de eventos de inicio Figura 2.25 Algunos tipos de eventos Intermedios Figura 2.26 Algunos tipos de eventos de Fin Figura 2.27 Algunos tipos de Actividades Figura 2.28 Algunos tipos demarcadores de tareas Figura 2.29 Tareas Figura 2.30 Compuertas Figura 2.31 Depósito de datos Figura 2.32 Conectores de objetos Figura 2.33 Canales Figura 2.34 Artefactos Figura 2.35 Ejemplo de Diagrama Ejecutable BPMN Figura 2.36 Ejemplo de Diagrama Ejecutable BPMN Figura 2.37 Ejemplo de contenedor Ejb Figura 2.38 Ciclo de vida de un stateless sesión beans Figura 2.39 Stateless Session Beans con Interface Remote Figura 2.40 Interface Remote del Stateless Session Beans Figura 2.41 Ciclo de vida de un stateful sesión beans Figura 2.42 Anotación de un stateful sesión beans Figura 2.43 Ciclo de vida de un singleton sesión beans Figura 2.44 Anotación que identifica a un singleton sesión beans Figura 2.45 Ciclo de vida de un message-driven bean Figura 2.46 Ejemplo de clase MDB Figura 2.47 Ejemplo de clase stateless session bean anotada 50 Figura 2.48 Ejemplo de clase Entity Figura 2.49 Ejemplo de relación uno a uno VI

8 Figura 2.50 Ejemplo de relación uno a muchos Figura 2.51 Ejemplo de relación muchos a uno Figura 2.52 Ejemplo de relación muchos a muchos Figura 2.53 Ejemplo de inyección de dependencia del EntityManager Figura 2.54 Ejemplo de método find sobre una entidad Figura 2.55 Ejemplo de persistencia de una entidad Figura 2.56 Ejemplo de eliminación de una entidad Figura 2.57 Ejemplo de archivo persistence.xml Figura 4.1 Resumen de la transformación propuesta Figura 4.2 Modelos MDA y el lenguaje utilizado para las transformaciones Figura 4.3 Transformación propuesta en el marco de la arquitectura de la OMG que sustenta MOF Figura 4.4 Componentes de la Propuesta Figura 4.5 Ejemplo genérico de diagrama BPMN Figura 4.6 Ejemplo genérico de diagrama BPMN 2 con visualizador de formato xmi Figura 4.7 Resultado de la Transformación BPMN 2.0 a UML Figura 4.8 Resultado de la Transformación BPMN 2.0 a UML 2. Paquete business. Vista UML Figura 4.9 Resultado de la Transformación BPMN 2.0 a UML 2. Paquete entities. Vista UML Figura 4.10 Diagrama de Clases UML 2 modificado por el desarrollador Figura 4.11 Perfil Independiente de la Tecnología Aplicado a una operación de una clase Figura 4.12 Perfil Independiente de la Tecnología Figura 4.13 Generación de model UML2 y Paquetes business y entities. Vista XMI Figura 4.14 Generación de model UML2 y Paquetes business y entities. Vista UML Figura 4.15 Transformación de Definition BPMN 2.0 a Package UML2. Vista QVT Relations Figura 4.16 Transformación Process BPMN 2 a Class UML 2. Vista XMI Figura 4.17 Transformación Process BPMN 2 a Class UML 2. Vista QVT Relations Figura 4.18 Transformación de Lane BPMN 2 a Class UML2. Vista XMI Figura 4.19 Transformación de Lane BPMN 2 a Class UML2. Vista QVT Relations 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 Figura 4.22 Transformación de ServiceTask BPMN 2 a Operation UML 2. Vista QVT Relations 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 Figura 4.25 Transformación de DataStore BPMN 2 a Operaciones UML 2. Vista QVT Relations 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 UML 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 Figura 4.30 Asociación de DataStore con Entidad Lane Figura 4.31 Parte de la transformación de un elemento DataStore BPMN 2 a elementos UML2. Vista QVT Relations 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 Figura 4.34 Transformación de Lane BPMN 2.0 a un elemento Class UML 2.0.Vista QVT Relations 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 Figura 4.37 Transformación de Participant BPMN 2 a elemento Class UML 2. Vista QVT Relations Figura 4.38 Diagrama de Clases UML 2 del Paquete business Modificado por el Desarrollador Figura 4.39 Diagrama de Clases UML 2 del Paquete entities modificado por el Desarrollador Figura 4.40 Componentes del paquete Business con Anotaciones Figura 4.41 Componentes del paquete Entities con Anotaciones Figura 4.42 Perfil Ejb 3.1-Web Services Figura 4.43 Perfil JPA Figura 4.44 Transformación de elementos en el paquete business. Vista XMI Figura 4.45 Transformación de elementos en el paquete business. Vista UML Figura 4.46 Código fuente de la relación ClassToSession. Vista QVT Relations VII

9 Figura 4.47 Código fuente de la relación OperacionesClases. Vista QVT Relations Figura 4.48 Transformación de Clases del Paquete entities. Vista XMI Figura 4.49 Transformación de Clases del Paquete entities.. Vista QVT Relations Figura 4.50 Transformación de asociaciones en paquete Entity Figura 4.51 Atributo marcado con el estereotipo <<Association>> 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 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 Figura 4.59Entidad Lane2 generada con Acceleo Figura 4.60 Estructura con los principales componentes del proyecto Acceleo Figura 4.61 Plantilla generarpackage Figura 4.62 Plantilla generatewebservice Figura 4.63 Plantilla generateentity Figura 4.64 Diagrama XMI origen con los componentes del paquete Business Figura 4.65 Plantilla generatecuerpowebservice del módulo cuerpowebservice Figura 4.66 Generación de métodos de las clases del paquete Business Figura 4.67 Método create de la Clase AbstractEntityService Figura 4.68 Transformación de una clase a código fuente JavaEE Figura 4.69 Diagrama XMI origen con los componentes del paquete entities Figura 4.70 Plantilla generatecuerpoentity del módulo cuerpoentity Figura 4.71 Anotación de propiedades con relaciones entre objetos Figura 4.72 Resultado de la transformación de las clase DataStore Figura 5.1 Pasos de una Iteración para obtener una Transformación Figura 5.2 Esquema general del proceso de mantenimiento Figura 5.3 Diagrama Técnico BPMN2 del caso de estudio Sistema de mantenimiento Figura 5.4 Diagrama BPMN 2 con visualizador de formato xmi Figura 5.5 Modelo resultante de la Transformación de un modelo BPMN 2.0 a un modelo UML 2 del Paquete entities Figura 5.6 Modelo resultante de la Transformación de un modelo BPMN 2.0 a un modelo UML 2 del Paquete Business Figura 5.7 Modelo resultante de la Transformación de un modelo UML2 a un modelo UML 2 del Paquete Entities Figura 5.8 Perfil Association aplicado a la propiedad solicitudreparacionitem Figura 5.9 Componentes JavaEE del Paquete Business generados en la Segunda Transformación Figura 5.10 Detalle de los Componentes de la Clase SectorServiceSessionBean Figura 5.11 Estructura de elementos Java EE generados por la transformación Acceleo Figura 5.12 Ejemplo de Código Fuente Generado para Clase Stateless Figura 5.13 Ejemplo de Código Fuente Generado para Clase Entity Figura 7.1 Elementos del núcleo de BPMN Figura 7.2 Elementos del núcleo de BPMN Figura 7.3 Ejemplo de Definitions Figura 7.4 Clases del paquete Foundations Figura 7.5 Clases del paquete Collaboration Figura 7.6 Clases del paquete Collaboration Figura 7.7 Clases del paquete Process Figura 7.8 Asociaciones y atributos de un modelo de proceso Figura 7.9 Ejemplo de elemento Process de tipo ejecutable Figura 7.10 Diagrama de clases para el elemento Task Figura 7.11 Diagrama de clases para el elemento Service Task Figura 7.12 Ejemplo de elemento Service Task Figura 7.13 Diagrama de clases para el elemento Data Store VIII

10 Figura 7.14 Ejemplo de DataStore Figura 7.15 Diagrama de clases para el elemento Lane Figura 7.16 Ejemplo de LaneSet y Lane Figura 7.17 Paquetes de Infrastructure Figura 7.18 Paquete Core y su relación con MOF y UML Figura 7.19 Paquetes de InfrastructureLibrary Figura 7.20 Elementos del Diagrama de Clases del Package Basic tomado de [17] Figura 7.21 Elementos del Diagrama de Paquetes tomado de [17] Figura 7.22 Elemento Class y sus relaciones tomado de [61] Figura 7.23 Elemento Operation y sus relaciones tomado de [61] Figura 7.24 Elemento Association y sus relaciones tomado de [61] Figura 7.25 Elemento package y sus relaciones tomado de [61] Figura 7.26 Paquetes de InfrastructureLibrary Figura 7.27 Elemento Interface y sus relaciones tomado de [61] Figura 7.28 Dependencia entre paquetes Profiles Figura 7.29 Los elementos del paquete Profiles, tomado de [61] Figura 7.30 Clasificación RAC Figura 7.31 Esquema general del proceso de RAC Figura 7.32 Diagrama Técnico BPMN2 del caso de estudio: Sistema de Guardia Hospitalario Figura 7.33 Diagrama BPMN 2 con visualizador de formato XMI Figura 7.34 Componentes generados en la primera transformación Figura 7.35 Parte del modelo generado en la primera Transformación en el Paquete entities. Versión Diagrama UML 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 Figura 7.38 Modelo resultante de la Transformación de un modelo UML2 a un modelo UML 2 del Paquete Entities Figura 7.39 Perfil Association aplicado a la propiedad encuentromedicoitem Figura 7.40 Componentes JavaEE del Paquete Business generados en la Segunda Transformación Figura 7.41 Detalle de los Componentes de la Clase MedicoServiceSessionBean Figura 7.42 Estructura de elementos Java EE generados por la transformación Acceleo Figura 7.43 Ejemplo de Código Fuente Generado para Clase Stateless Figura 7.44 Ejemplo de Código Fuente Generado para Clase Entity Figura 7.45 Paquetes de Infrastructure IX

11 Índice de Tablas Tabla 3.1 Resumen de las principales propuestas para las transformaciones de CIM a PIM Tabla 3.2 Características de la Propuesta Tabla 4.1 Descripción de Elementos del Perfil Independiente de la Tecnología Tabla 4.2 Generación de model UML2 y Paquetes business y entities. Vista textual Tabla 4.3 Regla de transformación de un Proceso BPMN 2.0 a una Clase UML 2.Vista textual Tabla 4.4 Regla de transformación de un elemento Lane BPMN 2.0 a una Clase UML 2. Vista textual Tabla 4.5 Transformación de ServiceTask BPMN 2 a Operation UML 2. Vista textual Tabla 4.6 Transformación de DataStore BPMN 2 a Operaciones UML 2. Vista textual Tabla 4.7 Transformación de un modelo BPMN 2.0 a Elementos Generales UML2. Vista textual Tabla 4.8 Transformación de un elemento DataStore BPMN 2 a elementos UML2. Vista Textual Tabla 4.9 Regla de transformación de un elemento Lane BPMN 2.0 a una Clase UML 2. Vista textual Tabla 4.10 Regla de transformación de un elemento Participant BPMN 2.0 a una Clase UML 2. Vista textual Tabla 4.11 Transformación de elementos en el paquete business.vista textual Tabla 4.12 Transformación de Clases del Paquete entities.vista textual Tabla 5.1 Casos de Estudio Tabla 6.1 Resumen de Resultados Tabla 7.1 Atributos para elemento Definiciones (Definitions) Tabla 7.2 Atributos Principales de Collaboration Tabla 7.3 Atributos Principales de Message Flow Tabla 7.4 Atributos Principales del elemento Process Tabla 7.5 Atributos Principales del elemento Service Task Tabla 7.6 Atributos Principales del elemento Script Task Tabla 7.7 Atributos Principales del elemento LaneSet Tabla 7.8 Atributos Principales del elemento Lane X

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

13 1.2 Objetivos de la Tesis Las organizaciones de la actualidad están en permanente cambio siendo una necesidad tener automatizados, total o parcialmente, sus procesos de negocio. Por esta razón, es imprescindible mantener la articulación o alineamiento entre los procesos del negocio y los sistemas informáticos. Se identifican dos problemas a resolver: Mejorar la automatización de la evolución de modelos abstractos de procesos a plataformas de implementación específicas. Lograr la consistencia entre procesos del negocio ejecutables, definidos mediante el estándar BPMN 2, y el software que automatiza a estos procesos. En base a la definición de los problemas se plantea la siguiente hipótesis de trabajo: Es factible transformar en forma automática y/o semiautomática modelos de procesos ejecutables definidos con el estándar BPMN 2.0 a componentes Java EE?. En base a la hipótesis planteada el objetivo general de esta tesis es: Transformar en forma automática y/o semiautomática modelos de procesos ejecutables definidos con el estándar BPMN 2.0 a componentes Java EE. Para lograr esto es necesario el desarrollo de perfiles, transformaciones en el marco de MDA y un método de trabajo. Entonces, los objetivos específicos se definen como: Diseñar perfiles UML 2, independientes y específicos de la plataforma. Desarrollar la transformación de un modelo técnico BPMN 2 a un diagrama de clases UML 2 [5] (modelo independiente de la plataforma). Desarrollar la transformación del diagrama UML 2 obtenido en el punto anterior a un diagrama UML 2 con estereotipos del perfil EJB 3.1-JPA 2 [6][7](Modelo dependiente de la plataforma). Desarrollar la transformación del último modelo a código fuente java que compone los elementos de la capa del negocio Java EE [8]. Diseñar un método de trabajo para el desarrollo y validación de las transformaciones. En el marco de la metodología MDA, se realizarán transformaciones para lograr los objetivos definidos a partir de la hipótesis planteada. Las dos primeras transformaciones se realizan con el lenguaje Relations que forma parte de Query/Views/Transformations (QVT) [4] y la última con la herramienta Acceleo [9] que se basa en el lenguaje MTL definido en 2

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

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

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

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

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

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

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

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

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

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

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

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

26 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 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; 15

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

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

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

30 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 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')] 19

31 Figura 2.11 Declaración de módulo Un ejemplo de la declaración de un módulo se puede observar en la figura [module generate(' 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 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 / /] Plantilla (templates) Figura 2.14 Ejemplo de import 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 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 20

32 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 [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 [query public obteneratributospublicos(c : Class) : Set(Property)= c.attribute->select(visibility=visiblilitykind::public) /] Figura 2.18 Ejemplo de consulta 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. 21

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

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

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

36 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. Descripción de las Fases Figura 2.21 El ciclo de BPM 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 25

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

38 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. Nivel 1. Procesos Descriptivos Figura 2.22 Niveles de Abstracción del BPMN Framework 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. 27

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

40 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 Inicio Elemento Descripción Notación Representa el inicio de un proceso Intermedio Fin Detiene el flujo hasta que ocurra una condición o dispara acciones de excepción 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 Elemento Descripción Notación Evento de inicio de mensaje El proceso inicia cuando se recibe un mensaje desde un participante (externo). Evento de inicio de temporización Una fecha-hora o un ciclo de tiempo (ej: cada Lunes a las 18:00hs) que cuando se cumple dispara el comienzo Evento de inicio de condición del proceso El proceso inicia cuando una condición de negocio se cumple. Figura 2.24 Algunos tipos de eventos de inicio 29

41 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 Elemento Descripción Notación Evento intermedio de Un mensaje arriba desde un mensaje participante (externo) y dispara el evento. Esto causa que el proceso continúe. También usado para enviar un mensaje a un participante. Si es usado para el manejo de excepciones, cambiará el flujo normal a uno de excepción Evento intermedio de temporización Evento intermedio de condición Evento intermedio de error 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 Se utiliza para esperar que una condición de negocio se cumpla.. 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. 30

42 Elemento Descripción Notación Evento de fin de mensaje Indica que un mensaje es enviado a un participante (externo) cuando finaliza el proceso Evento de fin de error Envía una excepción de error al finalizar el flujo. Actividades (Activity) Figura 2.26 Algunos tipos de eventos de Fin Representa algo realizado en un proceso. Consumen recursos. Pueden ser atómicas o compuestas. Las actividades son atómicas cuando están representadas con el menor nivel de detalle en el diagrama. Las actividades no atómicas son las compuestas, estas se pueden expandir a niveles más bajos de detalle en un diagrama. Elemento Descripción Notación Tarea Una tarea es una actividad simple que se utiliza cuando el trabajo realizado dentro del proceso no está definido en un nivel más detallado. Sub-Proceso Es una actividad compuesta cuyo detalle se define como un flujo de otras actividades. Marcadores de Tarea (Task Markers) Figura 2.27 Algunos tipos de Actividades BPMN especifica marcadores para las tareas. Las tareas pueden tener una o dos de estas marcas. En la figura 2.28, se pueden observar dos ejemplos de marcadores de tarea. Elemento Descripción Notación Loop Representa la ejecución repetida de una tarea en forma secuencial Múltiple Instancia Representa la ejecución de múltiples instancias de la tarea Tipos de Tareas (Task Types) Figura 2.28 Algunos tipos demarcadores de tareas 31

43 Los tipos de tareas son fundamentales para poder vincular los modelos técnicos de procesos del negocio con una plataforma tecnológica como Java EE. En este trabajo se utilizan los elementos Tarea de servicio y Tarea de Script para realizar transformaciones a UML. En la figura 2.29, se pueden observar los distintos tipos de tareas. Elemento Descripción Notación Tarea de Servicio Representa un servicio automatizado provisto por un servicio web o una aplicación. Tarea de Envío Representa el envío de un mensaje a un participante externo. Cuando el mensaje fue Tarea de Recepción enviado, la tarea finaliza. 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 Regla del Negocio Tarea de Script Una tarea que es ejecutada sin la asistencia de una aplicación o BPMS 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 Un script ejecutado por una máquina de proceso de un BPMS. El script se define en el lenguaje de script provisto por el 32

44 BPMS Figura 2.29 Tareas Compuertas (Gateways) Definen los tipos de comportamiento del flujo de secuencia de un proceso. Son elementos que controlan donde divergen o convergen los flujos de secuencia en un proceso. Utilizando flujos de secuencia se producen: la ramificación, bifurcación, combinación y unión de flujos en un proceso. A continuación, en la figura 2.30, se describen las compuertas básicas: Elemento Descripción Notación Exclusivo Se utiliza cuando en un punto del flujo se escoge un camino de varios disponibles, basado en los datos del proceso. Como convergencia es utilizada para confluir caminos excluyentes. Evento Se utiliza cuando en un punto del flujo se escoge un camino de varios disponibles. La selección del camino se basa en eventos, los caminos restantes se deshabilitan. Paralelo Se utiliza cuando varias actividades pueden realizarse concurrentemente o en paralelo. Como convergencia el flujo continuará cuando todos los caminos activos hayan confluido. Objeto de Datos (Data Object) Figura 2.30 Compuertas 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 33

45 simplificar las conexiones de un diagrama. Representan los datos o información consumidos o producidos por las actividades. El elemento DataStore fue incorporado en la última versión de BPMN y es utilizado en este trabajo como uno de los elementos orígenes para realizar transformaciones. En la figura 2.31, se describe el elemento DataStore. Elemento Descripción Notación Depósito de Datos (DataStore) Proporciona un mecanismo para que las actividades recuperen o actualicen información almacenada que persistirá más allá del alcance del proceso. Mediante un Data Store Reference el DataStore puede ser visualizado en distintos lugares de un proceso. El Data Store Reference se puede utilizar como origen o destino de una asociación de datos. Figura 2.31 Depósito de datos Conectores de Objetos (Connecting Objects) Definen la manera de vincular elementos como objetos de flujo y artefactos. En la figura 2.32, se pueden observar los conectores de objetos. Elemento Descripción Notación Flujo de Secuencia Define el orden en que las actividades se ejecutarán en un proceso. El origen y el destino del flujo de secuencia deben ser uno de los siguientes objetos de flujo: Eventos, Actividades y Gateways No puede cruzar los límites de un pool. Flujo de Mensajes Sirve para mostrar el flujo de mensajes entre dos 34

46 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. Canales (Swimlanes) Figura 2.32 Conectores de objetos 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 Elemento Descripción Notación 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. 35

47 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 Elemento Descripción Notación Grupo Agrupación de actividades para propósitos de documentación o análisis Anotaciones Usada para proveer información adicional a un diagrama. Figura 2.34 Artefactos 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. 36

48 Figura 2.35 Ejemplo de Diagrama Ejecutable BPMN 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 37

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

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

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

52 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 recompilació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 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 41

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

54 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 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 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 identifica a un pojo como un componente EJB stateless. se pueden inyectar referencias a un EntityManager que proporciona lo necesario para manejar la persistencia. Como se explica en la sección 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 43

55 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 caracteriza a una interfaz java como interfaz remota de un componente EJB. Figura 2.40 Interface Remote del Stateless Session Beans 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 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 antes de pasarlo al estado pasivo. Si un cliente 44

56 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 y luego pasa al estado de listo. Al final del ciclo de vida, el cliente invoca un método y el contenedor EJB llama al método 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 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 El contenedor ejecuta cualquier inyección de dependencia y luego invoca al método 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 si existe. El singleton session bean ya está listo para ser recolectado por el garbage Collection. 45

57 Figura 2.43 Ciclo de vida de un singleton sesión beans En la figura 2.44, se observa la que marca a una clase java como singleton sesión beans. Mientras que la 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 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 MessageDriven Debe ser definida como pública. La clase no puede ser definida como abstracta o final. 46

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

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

60 and Integration (UDDI). EJB permite crear Web Services a partir de stateless session beans [26] 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) 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 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 49

61 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 Ejemplo de Web Services con JAX-WS Un web service JAX-WS es una clase Java marcada con la 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 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 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 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 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. 50

62 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 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 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 Ejemplo En la figura 2.48, se muestra un ejemplo de una clase entidad JPA. La clase Articulo se marca con la y el atributo id se marca con la 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 para permitir identificar en forma única cada instancia de una entidad. Comúnmente se utiliza un atributo de tipo Integer para ser anotado La da la posibilidad de que la base de datos relacionada con la entidad genere en forma única e incremental el valor del atributo identificador. 51

63 Figura 2.48 Ejemplo de clase Entity Relaciones entre entidades Se pueden establecer cuatro tipo de relaciones entre entidades: Uno a Uno a Muchos a Muchos a 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 52

64 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 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. Asociación Uno a Muchos Figura 2.49 Ejemplo de relación uno a uno 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 En la Clase cliente el atributo colección utilizado es dirección. Asociación Muchos a Uno Figura 2.50 Ejemplo de relación uno a muchos 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 sobre la propiedad departamento de la clase empleado. 53

65 Asociación Muchos a Muchos Figura 2.51 Ejemplo de relación muchos a uno 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 sobre cada atributo persistente de tipo colección de cada entidad. Figura 2.52 Ejemplo de relación muchos a muchos 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. 54

66 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. Persistencia de una entidad Figura 2.54 Ejemplo de método find sobre 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 55

67 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. Eliminar una entidad Figura 2.55 Ejemplo de persistencia de 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 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. 56

68 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). 57

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

70 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 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] 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 59

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

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

73 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 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) 62

74 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]. 63

75 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, Garci a-rodri guez 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. 64

76 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: 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 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. 65

77 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 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 SI SI NO SI SI NO NO SI formalizadas 2.3 Metamodelos estándares Parcial Parcial NO SI SI NO NO SI 3 Alineamiento entre el Negocio y los Sistemas Informáticos Nuestra Propuest a Parcial Parcial Parcial Parcial Parcial Parcial Parcial Parcial 4 Integración con BPMS NO NO NO NO NO NO NO SI 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 : 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. 66

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

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

80 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 Uso de Estándares Lenguaje de modelado estándares Se cubren niveles CIM, PIM, PSM y componentes del negocio. Se definen las transformaciones MDA entre los modelos. Nivel CIM: Modelado de procesos del negocio: BPMN 2.0 Nivel PIM: UML 2 Nivel PSM: UML 2 con perfiles UML Se utiliza el estándar de la OMG. El lenguaje QVT- Relations. Se utilizan metamodelos completos basados en estándares. Transformaciones formalizadas Metamodelos estándares Alineamiento entre el Se definen transformaciones desde el nivel CIM Negocio y los Sistemas Informáticos 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 69

81 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). 70

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

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

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

85 Figura 4.4 Componentes de la Propuesta 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 y el perfil independiente de la plataforma se explica en la sección Desde la sección hasta la sección 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. 74

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

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

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

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

90 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 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 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 uml::package nombre business. 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. 79

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

92 4.2.4 Transformación de un elemento Process de BPMN 2.0 a un elemento Class UML 2.0 En la tabla 4.3 y en la figura 4.16 se explica la transformación de un elemento Process a una clase contenida en el paquete business. La clase se crea dentro del Package business si se cumple la precondición de que no existen elementos Lane dentro del modelo origen. Las clases creadas dentro del package business luego son transformadas en componentes Session Bean del modelo específico de la plataforma. En la figura 4.17, se define el código QVT de la relación. Tabla 4.3 Regla de transformación de un Proceso BPMN 2.0 a una Clase UML 2.Vista textual. Modelo Origen Reglas de Transformación Modelo Destino bpmn2::process El elemento Process de BPMN 2 se transforma en un elemento Class de UML 2 dentro del Package business. uml::packageableelement::class. Anotada con <<WebService>> Origen Transformación Destino Figura 4.16 Transformación Process BPMN 2 a Class UML 2. Vista XMI. 81

93 Figura 4.17 Transformación Process BPMN 2 a Class UML 2. Vista QVT Relations 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. 82

94 Uno de los patrones de diseño utilizado para definir una clase dentro del paquete business consiste en generar una clase por cada caso de uso. Las secuencias de tareas sin interrupción contenidas en un elemento Lane las podemos considerar como equivalentes a un caso de uso. En este caso utilizamos el concepto de Step, que consiste en definir un caso de uso por cada secuencia de tareas sin interrupción de un actor [52]. Teniendo en cuenta esto se genera una clase fachada de servicios por cada conjunto de tareas contenidas en un elemento Lane. La clases generadas a partir del elemento Lane son marcadas con la anotación <<WebService>>. Tabla 4.4 Regla de transformación de un elemento Lane BPMN 2.0 a una Clase UML 2. Vista textual. Modelo Origen Reglas de Transformación Modelo Destino bpmn2::lane El elemento Lane de Bpmn 2 se transforma en un elemento Class de UML dentro del Package Business. uml::packageableelement::cl ass. Anotada con <<WebService>>. Origen Transformación Destino Figura 4.18 Transformación de Lane BPMN 2 a Class UML2. Vista XMI. En la figura 4.19, se presenta el código de la relación LaneToClass, donde se define la precondición que solo permite crear una clase por cada Lane si el número de elementos Lane en el modelo origen es mayor a cero. En la cláusula where se encuentra la llamada al código que aplica la anotación a la clase UML 2 generada. 83

95 Figura 4.19 Transformación de Lane BPMN 2 a Class UML2. Vista QVT Relations Transformación de un elemento ServiceTask de BPMN 2.0 a un elemento Operation de una Clase UML 2.0 En la tabla 4.5 y en las figuras 4.20 y 4.21, se explica la transformación de un elemento ServiceTask de BPMN 2.0 a un elemento Operation de una Clase UML 2.0. Teniendo en cuenta que un elemento ServiceTask de BPMN 2.0 se utiliza para representar un servicio web. Entonces, se transforma este elemento en una operación UML 2 marcada como método web con la anotación <<WebMethod>>. Tabla 4.5 Transformación de ServiceTask BPMN 2 a Operation UML 2. Vista textual. Modelo Origen Reglas de Transformación Modelo Destino bpmn2::servicetask El elemento ServiceTask de Bpmn 2 se transforma en un elemento Operación dentro de un elemento Class de UML, dentro del paquete business. uml::operation. Anotada con WebMethod. 84

96 Origen Transformación Destino Figura 4.20 Transformación de ServiceTask BPMN 2 a Operation UML 2. Vista XMI. Figura 4.21 Transformación de ServiceTask BPMN 2 a Operation UML 2. Vista UML 2. En la figura 4.22, se puede observar el código de la relación ServiceToOperation. Figura 4.22 Transformación de ServiceTask BPMN 2 a Operation UML 2. Vista QVT Relations. 85

97 4.2.7 Transformación de un elemento DataStore de BPMN 2.0 a elementos Operation de una Clase UML 2.0 En la tabla 4.6 y en las figuras 4.23 y 4.24, se explica la transformación de un elemento DataStore de BPMN 2.0 a elementos Operation de una Clase UML 2.0. El motivo de esta transformación es generar las operaciones necesarias para poder gestionar la clase persistente que se crea luego en la sección 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 uml::operations. Con Bpmn 2 de se transforma en Operaciones UML 2 de una anotaciones: create, update, deactivate, search. clase dentro del paquete entities. Origen Transformación Destino Figura 4.23 Transformación de DataStore BPMN 2 a Operaciones UML 2. Vista XMI. Figura 4.24 Transformación de DataStore BPMN 2 a Operaciones UML 2. Vista UML 2. En la figura 4.25, se puede observar una parte del código de la relación que realiza la transformación. Se puede ver como en la cláusula enforce genera la operación add (agregar). Luego la operación add es marcada con la anotación Create. El resto del código fuente la transformación se puede ver en el Anexo 3. 86

98 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 Transformación de un modelo BPMN 2.0 a Elementos Generales UML2 En la tabla 4.7 y en las figuras 4.26 y 4.27, se explica la transformación de un elemento Definitions de BPMN 2.0 a elementos clases y asociaciones de UML 2. El motivo de esta transformación es generar clases generales cuyos elementos puedan ser heredados por las clases del modelo generado. La clase EntityGeneral contiene atributos generales como description(descripción), active (activo), company (empresa) y user (usuario). El campo active determina si una instancia esta anulada o no. La clase company sirve para que el modelo generado contemple la posibilidad de gestionar objetos de distintas empresas. La clase user permite vincular a cada registro con un usuario. Las clase generadas son marcadas con la anotación <<Entity>>. 87

99 Tabla 4.7 Transformación de un modelo BPMN 2.0 a Elementos Generales UML2. Vista textual. Modelo Origen Reglas de Transformación Modelo Destino bpmn2::definitions El elemento Definitions de Bpmn 2 se transforma en clases y asociaciones UML 2 que son utilizadas por otros elementos del modelo generado. uml::class (EntityGeneral) uml::class (User) uml::class (Company) uml:associations Anotadas con <<Entity>> Origen Transformación Destino Figura 4.26 Transformación de un modelo BPMN 2.0 a Elementos Generales UML2. Vista XMI. Figura 4.27 Diagrama UML2 destino. Elementos Generales UML Transformación de un elemento DataStore a elementos UML 2 En la tabla 4.8 y en las figuras 4.28 y 4.29, se explica la transformación de un elemento DataStore de BPMN 2.0 a elementos clases y asociaciones de UML 2. El modelo resultante se utiliza en la transformación explicada en la sección 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. 88

100 Tabla 4.8 Transformación de un elemento DataStore BPMN 2 a elementos UML2. Vista Textual. Modelo Origen Reglas de Transformación Modelo Destino bpmn2::datastore El elemento DataStore de Bpmn 2 se transforma en clases y asociaciones UML 2 dentro del Package entities. Elementos Class y Associations. Las entidades son anotadas con <<Entity>>. Origen Transformación Destino Figura 4.28 Transformación de un elemento DataStore BPMN 2 a elementos UML2. Vista XMI. Figura 4.29 Transformación de un elemento DataStore BPMN 2 a elementos UML2. Vista UML 2. Como se explica en la sección , 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 Figura 4.30 Asociación de DataStore con Entidad Lane 89

101 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 Transformación de un elemento Lane de BPMN 2.0 a un elemento Class UML 2.0 En el caso que en el modelo BPMN 2 origen existan elementos Lane dentro de un elemento Process estos son transformados en Clases dentro del Package business. Como se muestra en la figura 4.26, el modelo BPMN 2 está formado por un proceso compuesto por un elemento LaneSet que a su vez contiene elementos Lane. En la tabla 4.9 y en las figuras 4.32 y 4.33, se explica la transformación de un elemento Lane de BPMN 2.0 a una clase UML 2. La transformación se fundamenta en estimar que un elemento Lane de BPMN 2.0 puede ser en el modelo destino una clase persistente. Tabla 4.9 Regla de transformación de un elemento Lane BPMN 2.0 a una Clase UML 2. Vista textual. Modelo Origen Reglas de Transformación Modelo Destino 90

102 bpmn2::lane El elemento Lane de Bpmn 2 se transforma en un elemento Class de UML dentro del Package Business. uml::packageableelement::cl ass. La clase es anotada con <<Entity>>. Origen Transformación Destino Figura 4.32 Transformación de Lane BPMN 2.0 a un elemento Class UML 2.0.Vista XMI. Figura 4.33 Transformación de Lane BPMN 2.0 a un elemento Class UML 2.0.Vista UML 2. En la figura 4.34, se puede observar el código QVT Relations de la relación LaneToClass. Se puede ver en el código que se verifica si el proceso que contienen al elemento Lane es ejecutable. También se puede observar que se define la precondición que sólo permite crear una clase por cada Lane, si el número de elementos Lane en el modelo origen es mayor a cero. En la relación LaneToClassEntity1 se aplica a la clase la anotación <<Entity>>. 91

103 Figura 4.34 Transformación de Lane BPMN 2.0 a un elemento Class UML 2.0.Vista QVT Relations Transformación de un elemento Participant de BPMN 2.0 a un elemento Class UML 2.0 En la tabla 4.10 y en las figuras 4.35 y 4.36, se explica la transformación de un elemento Participant de BPMN 2.0 a una clase UML 2. La transformación se fundamenta en estimar que un elemento Participant de BPMN 2.0 puede ser en el modelo destino una clase persistente. Tabla 4.10 Regla de transformación de un elemento Participant BPMN 2.0 a una Clase UML 2. Vista textual. Modelo Origen Reglas de Transformación Modelo Destino bpmn2::participant El elemento Participant de Bpmn 2 se transforma en un elemento Class de UML dentro del Package Entities. uml::packageableelement::cl ass 92

104 Origen Transformación Destino Figura 4.35 Transformación de Participant BPMN 2 a elemento Class UML 2. Vista XMI. Figura 4.36 Transformación de Participant BPMN 2 a elemento Class UML 2. Vista UML 2. En la figura 4.37, se puede observar el código QVT Relations de la relación ParticipantToClass 93

105 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 En la sección 2.5, se desarrollan los temas de JavaEE y JPA2. Desde la sección hasta la sección 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. 94

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

107 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 y 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. 96

108 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>>, 97

109 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 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). 98

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

111 Figura 4.43 Perfil JPA Transformaciones del paquete Business Esta transformación toma las clases del paquete Business con la anotación <<WeServices>> y las transforma en clases UML con el estereotipo <<Stateless, WebService>>. Estas clases heredan métodos generales de la clase AbstractEntityService que es creada para ayudar a la generación de métodos básicos como crear o modificar objetos. Por cada operación anotada en el modelo origen con el estereotipo independiente de la tecnología <<WebMethod>> la transformación genera los métodos correspondientes en el destino con la anotación <<WebMethod>> del perfil JavaEE. También genera una interface con estereotipos <<remote>> y <<local>> con sus respectivos métodos. En la tabla 4.11 y en las figuras 4.44 y 4.45, se explican las transformaciones en el paquete business. El código fuente de la relación se puede ver en el anexo 4. Tabla 4.11 Transformación de elementos en el paquete business.vista textual. Modelo Origen Reglas de Transformación Modelo Destino uml:class (con Se crea en el modelo destino una uml:class Clase anotaciones clase AbstractEntityService. AbstractEntityService independientes de la tecnología). El elemento Class de UML se transforma en un elemento Class en el modelo destino con anotaciones <<Stateless, WebService>>. uml:class (con anotaciones Stateless y 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: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. 100

112 Figura 4.44 Transformación de elementos en el paquete business. Vista XMI. 101

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

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

115 Figura 4.47 Código fuente de la relación OperacionesClases. Vista QVT Relations Transformaciones del paquete Entities Las clases del paquete Entities son transformadas en clases con la anotación <<Entity>>. A las asociaciones entre clases se les agrega el estereotipo <<Association>> y mediante el atributo AssociationType, se define la cardinalidad: one-to-one, one-to-many, many-to-one, o many-to-many según corresponda. La relación ClassToEntity transforma las clases con sus componentes en entidades anotadas con el estereotipo <<Entity>>. En la tabla 4.12 y en las figuras 4.48 y 4.49, se explica la transformación. Tabla 4.12 Transformación de Clases del Paquete entities.vista textual. Modelo Origen Reglas de Transformación Modelo Destino uml:class (con El elemento Class de UML2 con uml:class (con anotaciones anotaciones independiente de la anotaciones independiente de la tecnología se transforma en un Entity del perfil JavaEE- JPA2). tecnología). elemento Class en el modelo destino con anotaciones <<Entity >>. 104

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

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

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

119 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 se muestra un ejemplo, en la sección se describen las características y funcionamiento general del proyecto desarrollado con la herramienta Acceleo, en la sección se analizan las transformaciones del paquete business y en la sección las transformaciones del paquete entities 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). 108

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

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

122 Figura 4.59Entidad Lane2 generada con Acceleo 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 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 111

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

124 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 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 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 Transformación del Paquete Entities. Figura 4.63 Plantilla generateentity Transformaciones del Paquete Business En base al modelo UML 2 con perfiles EJB3.1-JPA2 generado en la sección se explica la transformación a código fuente javaee del paquete business. 113

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

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

127 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 Transformación del Paquete Entities En base al modelo generado en la sección 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. 116

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

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

130 El código fuente de las transformaciones usando la herramienta Acceleo se puede ver en el Anexo 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 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 y 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 119

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

132 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, y 5.1.3, se sigue la numeración y los pasos que se muestran en la figura

133 Figura 5.1 Pasos de una Iteración para obtener una Transformación 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. 122

134 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 Método de Trabajo Aplicado a la transformación de un modelo UML2 con perfil independiente de la plataforma a un modelo UML2 con perfil Ejb3.1-JPA2 A continuación se explican las etapas del método utilizado en la segunda transformación en base al flujo de la figura 5.1. A.2 Iniciar desde Modelo UML 2 (Origen) Se utiliza como origen el modelo UML 2 con perfil independiente de la plataforma generado por la transformación anterior. B Crear la Transformación 123

135 En base al modelo UML 2 con perfil independiente de la plataforma generado por la transformación anterior se genera un modelo UML 2 con perfil independiente de la plataforma JavaEE. La transformación se crea utilizando el estándar QVT. Se crea un perfil JavaEE que se aplica en el modelo destino generado. Para poder lograr los objetivos se elabora un informe sobre la transformación y sobre el perfil Java EE creado. C Probar la Transformación (Validar la transformación) En base a los objetivos definidos para la transformación el grupo de expertos crea un modelo UML 2 con perfil JavaEE. Se verifican si son correctas las relaciones entre los elementos del modelo generado por la transformación y los elementos del modelo diseñado por expertos. D Modificar la Transformación En el caso de que no exista coincidencia entre el/los elemento/s del modelo origen y destino se revisa la transformación y en base al error detectado se modifica la transformación para corregir el problema. Modelo UML 2 (Destino) Como producto de la transformación se obtiene un modelo UML 2 con perfil Ejb3.1-JPA Método de Trabajo Aplicado a la transformación de un modelo UML2 con perfil Ejb3.1-JPA2 a Código Fuente JavaEE A continuación se explican las etapas del método utilizado en la tercera transformación en base al flujo de la figura 5.1. A.2 Modelo UML 2 Se utiliza como origen el modelo UML2 con perfil JavaEE generado por la transformación anterior. B Crear la Transformación Utilizando la herramienta Acceleo basada en el lenguaje MTL definido en la especificación de la OMG MOFM2T [10] se define la transformación a código fuente Java EE. Se estudia y elabora informe sobre la transformación. C Probar la Transformación (Validar la transformación) En base a los objetivos definidos para la transformación el grupo de expertos crea con la herramienta eclipse los componentes de software Java EE que debería generar la transformación. Se verifican si son correctas las relaciones entre los elementos del código 124

136 fuente generado por la transformación y los elementos del código fuente diseñado por expertos. D Modificar la Transformación En el caso de que el código fuente generado no sea correcto se modifica la transformación para corregir el problema. Código Fuente Java EE (Destino) El código fuente generado representa a los componentes del negocio Java EE y es el producto final de las tres transformaciones sucesivas aplicadas. Se cumple el objetivo final de transformar un proceso del negocio técnico BPMN 2 en componentes de software. El código fuente está alineado con modelos UML 2 y este a su vez con un proceso del negocio BPMN 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 125

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

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

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

140 Figura 5.4 Diagrama BPMN 2 con visualizador de formato xmi 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 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

141 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

142 Figura 5.6 Modelo resultante de la Transformación de un modelo BPMN 2.0 a un modelo UML 2 del Paquete Business 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 del capítulo 4. Por ejemplo, las asociaciones entre clases son anotadas con el estereotipo dependiente de la tecnología Association. 131

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

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

145 Figura 5.10 Detalle de los Componentes de la Clase SectorServiceSessionBean 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. 134

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

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

148 Se muestra como las versiones finales de las transformaciones y perfiles creados han pasado por varias etapas de refinamiento y validación. Se explican los casos de laboratorio y reales utilizados para demostrar el funcionamiento de las transformaciones. El objetivo del capítulo ha sido demostrar la validación de las tres transformaciones desarrolladas para cumplir con el objetivo de la tesis de transformar en forma automática y/o semiautomática modelos de procesos ejecutables definidos con el estándar BPMN 2 a componentes Java EE. En el próximo capítulo se presentan las conclusiones de esta tesis. 137

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

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

151 En las secciones 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 140

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

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

154 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 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 Nivel CIM: Modelado de procesos del negocio: BPMN 2.0 estándares Nivel PIM: UML 2 con perfil UML independiente de la plataforma. Nivel PSM: UML 2 con perfiles UML 143

155 Transformaciones formalizadas Metamodelos estándares Alineamiento entre el Negocio y los Sistemas Informáticos Integración con BPMS 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. Se utilizan metamodelos completos basados en estándares. Se definen transformaciones desde el nivel CIM 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. 144

156 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 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), th 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 145

157 perfiles planteados. Se pueden agregar nuevas transformaciones relacionadas con los elementos del metamodelo BPMN 2 como timer y reglas del negocio. El Interaction Flow Modeling Language (IFML) [61] es un estándar de la OMG, centrado en el modelado independiente de la plataforma de interfaces gráficas de usuarios. La generación de interfaces de usuarios utilizando la herramienta Acceleo a partir de un modelo IFML es algo que se puede implementar y relacionar con las transformaciones propuestas. Nos parece que este podría ser un aporte muy importante a las transformaciones ya planteadas en este trabajo de tesis. De esta forma, quedarían cubiertos casi todos los aspectos de la arquitectura de una aplicación empresarial. 6.4 Conclusiones finales Las organizaciones de la actualidad están en permanente cambio siendo una necesidad tener automatizados total o parcialmente sus procesos de negocio. La mejora continua en las organizaciones implica rediseñar, mejorar o introducir nuevos procesos de negocio de forma eficaz y eficiente manteniendo su integración con los sistemas informáticos de la organización. Por esta razón, es imprescindible mantener la articulación entre los procesos del negocio y los sistemas informáticos. Las transformaciones en el contexto de MDA es una alternativa válida para cumplir con este objetivo. En este trabajo de tesis se ha generado una propuesta MDA donde se han utilizado en todas sus etapas: estándares, herramientas y componentes de código abierto. El objetivo ha sido seguir un método que permita a partir de un modelo CIM basado en el estándar BPMN 2 definir transformaciones con el estándar QVT para generar modelos UML 2 y en base a estos modelos dar la posibilidad de obtener código fuente Java con transformaciones MTL. Siguiendo un método de trabajo se han ido generando versiones cada vez más refinadas de las transformaciones. Estas versiones han ido evolucionando a partir de los problemas y requerimientos surgidos a partir de la validación y pruebas con los casos de estudio reales y de laboratorio diseñados. Se diseñan y se utilizan en las transformaciones perfiles: independiente de la plataforma, Ejb 3.1-Web Services y JPA 2. Para realizar las transformaciones se ha utilizado la herramienta Medini QVT que permite la ejecución de transformaciones QVT expresadas con la sintaxis textual del lenguaje Relations. Para transformación de modelos UML 2 con perfiles a los componentes Java EE se utiliza la herramienta Acceleo que utiliza el lenguaje estándar MTL. La propuesta beneficia al desarrollo de software permitiendo aumentar la calidad y disminuir errores de diseño. Al basarse en UML 2 estándar el desarrollador puede tomar los modelos UML de las transformaciones y agregar los detalles necesarios que permitan cumplir con los requerimientos de los usuarios y del análisis y diseño Orientado a Objetos. Al utilizar como modelo origen una instancia del metamodelo estándar BPMN 2. Este modelo sirve de entrada para un BPMS (Business Process Management Suite) y para nuestra herramienta MDA permitiendo la interoperación entre ambas. 146

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

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

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

161 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 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: Identifica el espacio de nombres asociado con Definitions y la string convención establecida por el esquema XML. expressionlanguage: Identifica mediante el formato URI el lenguaje de expresión string [0..1] formal utilizado. Por defecto typelanguage: string Identifica el tipo de sistema usado por los elementos de [0..1] Definitions. Por defecto Debe estar en formato URI. 150

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

163 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

164 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 Name: String participants: Participant [0..*] messageflow: Message Flow [0..*] Descripción El nombre del elemento Collaboration Proporciona la lista de participantes que se utilizan en la colaboración. Los participantes se muestran como pools en una colaboración 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. 153

165 Comúnmente un participante es responsable de la ejecución de un Proceso encerrado en un Pool, sin embargo, un Pool puede ser definido sin un proceso. La figura 7.6, muestra la relación de los elementos participantes y de mensajes de flujo con una colaboración contenida en un elemento Definitions. Figura 7.6 Clases del paquete Collaboration Flujo de Mensaje (Message Flow) Un flujo de mensajes modela el flujo de mensajes entre dos participantes. Un flujo de mensajes debe conectar dos Pool separados. Se conectan en el límite del Pool. No pueden conectar a elementos dentro del Pool. En la figura 7.5, se muestra la relación entre un Message Flow y la clase Collaboration. La tabla 7.3 muestra los atributos utilizados en este trabajo para el modelado de mensajes de flujo. Tabla 7.3 Atributos Principales de Message Flow Nombre de Atributo Descripción name: string El nombre del elemento Message Flow. sourceref: El elemento desde el cual se conecta el flujo de mensaje. InteractionNode targetref: El elemento a donde se conecta el flujo de mensaje. InteractionNode 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. 154

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

167 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 Descripción Atributo processtype: El atributo processtype proporciona información sobre el nivel de ProcessType = none abstracción de modelado de un proceso. Un proceso público sólo { None Private muestra los elementos de flujo que son relevantes para los Public 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 isexecutable: boolean [0..1] defecto, el atributo processtype es "none", es decir, sin definir. 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 Tipos de procesos del Negocio Hay tres tipos básicos de procesos BPMN: Privados no ejecutables(internos) 156

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

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

170 Figura 7.11 Diagrama de clases para el elemento Service Task La tabla 7.5, muestra los atributos utilizados en este trabajo para el modelado del elemento Service Task. Tabla 7.5 Atributos Principales del elemento Service Task Nombre de Atributo Descripción implementation: Con este atributo se define la tecnología que se utiliza para enviar y string = recibir los mensajes. Los valores válidos pueden ser "# # ##webservice 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. Tarea de Script (Script Task) Figura 7.12 Ejemplo de elemento Service 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. 159

171 Tabla 7.6 Atributos Principales del elemento Script Task Nombre de Descripción Atributo scriptformat: string Define el formato del Script [0..1] script: string [0..1] El modelador puede incluir un script que se puede ejecutar cuando la tarea se lleva a cabo 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 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. 160

172 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 Carril (Lane) El elemento Lane representa a una entidad responsable de un proceso. Un Lane es una subpartició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. 161

173 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 Descripción Atributo 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 La referencia a un elemento Lane que es el padre de este LaneSet. [0..1] Un elemento Lane define una partición específica en un LaneSet. Los Lanes dentro de un LaneSet deben definir elementos del mismo tipo. El elemento Lane hereda los atributos y las asociaciones de modelo de BaseElement. En la Tabla 7.8, se muestran los atributos utilizado en el modelado del elemento Lane. Tabla 7.8 Atributos Principales del elemento Lane Nombre de Atributo Descripción name: sting [0..1] El nombre del elemento Lane. partitionelement: Una referencia a un elemento BaseElement que especifica el valor BaseElement [0..1] y el tipo de la partición. Utilizando este elemento de partición un herramienta compatible con el estándar BPMN puede determinar 162

174 partitionelementref: BaseElement [0..1] childlaneset: LaneSet [0..1] flownoderefs: FlowNode [0..*] los elementos de flujo que tienen que ser particionados en este Lane. 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. Una referencia a un elemento LaneSet para Lanes embedidos. 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 163

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

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

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

178 Paquete Basic del Core El paquete Basic pertenece al paquete Core dentro del InfrastructureLibrary como se muestra en la figura 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 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. 167

179 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] Paquete Constructs del Core El paquete Constructs pertenece al paquete Core dentro del InfrastructureLibrary como se muestra en la figura 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 168

180 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. Semántica Figura 7.22 Elemento Class y sus relaciones tomado de [61] 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. 169

181 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>] ] 170

182 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: 171

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

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

185 Figura 7.25 Elemento package y sus relaciones tomado de [61] 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. 174

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

187 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] 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 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. 176

188 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] 177

189 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 ( 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. 178

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

191 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) 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 180

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

193 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

194 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

195 Figura 7.37 Modelo Generado en la primera Transformación en el Paquete Business. Versión XMI 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 del capítulo 4. Por ejemplo, las asociaciones entre clases son anotadas con un estereotipo dependiente de la tecnología con nombre Association. 184

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

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

198 Figura 7.41 Detalle de los Componentes de la Clase MedicoServiceSessionBean 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. 187

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