cenidet Centro Nacional de Investigación y Desarrollo Tecnológico Departamento de Ciencias Computacionales

Transcripción

1 cenidet Centro Nacional de Investigación y Desarrollo Tecnológico Departamento de Ciencias Computacionales TESIS DE MAESTRÍA EN CIENCIAS EN CIENCIAS DE LA COMPUTACIÓN Generación de Especificaciones WSDL de Servicios Web a partir de Modelos Organizacionales Orientados a Servicios presentada por: Itzel Morales Ramírez Lic. en Informática por la Universidad Veracruzana como requisito para la obtención del grado de: Maestría en Ciencias en Ciencias de la Computación Director de tesis: Dr. Hugo Estrada Esquivel Asesorías de la Universidad Politécnica de Valencia: Dr. Oscar Pastor López Jurado: Dr. Guillermo Rodríguez Ortiz Dr. Juan Gabriel González Serna M.C. Mario Guillén Rodríguez Dr. Hugo Estrada Esquivel Presidente Secretario Vocal Vocal suplente Cuernavaca, Morelos, México. 06 de octubre de 2009

2 Resumen El objetivo general de este proyecto de tesis es el desarrollo de una metodología para generar especificaciones WSDL de servicios Web a partir de modelos organizacionales orientados a servicios. Esta metodología utiliza el enfoque de la arquitectura dirigida por modelos (MDA) para asegurar la precisión en la transformación de modelos. La metodología propuesta para la generación de las especificaciones, como ya se ha hecho mención, considera un enfoque MDA (Model Driven Architecture). Este enfoque involucra el manejo de varias tecnologías y especificaciones que la OMG (Object Management Group) acepta y reconoce por su factibilidad. El primer paso para lograr la obtención de las especificaciones WSDL es la creación de un modelo organizacional, el cual es serializado y almacenado como un documento XML. Como segundo paso este modelo es transformado a las especificaciones WSDL y BPEL aplicando las reglas de transformación. Una vez que las especificaciones han sido generadas se pueden obtener los servicios Web a partir de los documentos WSDL y con el documento BPEL establecer la orquestación de los servicios. Las pruebas realizadas se conforman de: a) la creación de los modelos organizacionales orientados a servicios utilizando un prototipo; b) la serialización de la especificación en XML; c) la transformación a documentos WSDL y BPEL mediante las reglas de transformación; y d) la validación de los documentos con la herramienta NetBeans IDE 6.5 y JDeveloper 11g. Por último, se describen las conclusiones y aportaciones generadas con el desarrollo y evaluación de este trabajo de investigación, además de la propuesta del trabajo futuro que complementaría el presente trabajo de tesis.

3 Abstract The overall objective of this thesis is the development of a methodology to generate WSDL specifications of Web services from business models oriented to services. This methodology uses the approach on model driven architecture (MDA) to ensure accuracy in the transformation of models. The proposed methodology for the generation of specifications, as outlined above, consider a MDA approach (Model Driven Architecture). This approach involves the handling of various technologies and specifications that OMG (Object Management Group) agrees and acknowledges their feasibility. The first step towards obtaining the WSDL specification is the creation of an organizational model, which is serialized and stored as an XML document. As a second step this model is transformed to WSDL and BPEL specifications using transformational rules. Once the specifications have been generated Web services can be obtained from WSDL documents and using the BPEL document to establish the orchestration of services. Tests are satisfied with: a) the creation of business models oriented to services using a prototype; b) the serialization of the specification in XML; c) the transformation to WSDL and BPEL documents using the transformational rules; and d) the validation of documents with the NetBeans IDE 6.5 and JDeveloper 11g tools. Finally, there is a description of the findings and contributions generated by the development and evaluation of this research work, as well as a proposal work which would complement this thesis.

4

5 Contenido Contenido Índice de figuras... iv Índice de tablas... vi Introducción... 1 Capítulo 1 Antecedentes Antecedentes A service-oriented approach for the i* Framework [ESTR08] Impact of service orientation at the business level [CHER05] e-service Design Using i* and e 3 value Modeling [JAAP06] Planteamiento del problema Objetivo Justificación y beneficios Estado del arte Designing Web Services with Tropos [LAUD04] Design Methodology for Web Services and Business Processes [PAPA02] Model Driven Design of Web Service Operations using Web Engineering Practices [RUIZ07] Model-driven Web Service Development [GRØN04] WSDL Automatic Generation from UML Models in a MDA Framework [VARA05] Generación de Aplicaciones Web Basadas en Procesos de Negocio Mediante Transformación de Modelos [TORR07] Applying MDA Approach for Web Service Platform [BEZI04] Análisis comparativo Alcances y limitaciones Capítulo 2 Marco teórico Arquitectura Dirigida por Modelos MDA Transformación de modelos Técnica de modelado de negocios Tropos Modelado organizacional orientado a servicios Arquitectura orientada a servicios SOA Modelo organizacional orientado a servicios Servicios Web Descripciones WSDL de servicios Web Estructura del documento WSDL Lenguaje BPEL4WS Estructura del documento BPEL4WS Capítulo 3 Lenguajes de transformación OCL (Object Constraint Language) Lenguajes de transformación ATL (ATLAS Transformation Language) QVT (Query View Transformation) MOFScript XSLT (Transformation XSL) I

6 Contenido 3.3 Lenguaje a usar en este proyecto Lenguaje MOFScript Transformación de texto Reglas del punto de entrada Reglas Propiedades y variables Archivos Declaración de impresión Otras opciones Herramienta MOFScript Capítulo 4 Definición del metamodelo para la transformación MOF Arquitectura de cuatro niveles Metamodelos Perfil UML Metamodelo basado en EMF Ecore Selección del metamodelo EMF Ecore Metamodelo intermedio MOS Características del metamodelo Selección de elementos del metamodelo MOS a ser mapeados a elementos WSDL y BPEL4WS Descripción de los atributos de los elementos MOS Atributos del servicio compuesto Atributos del servicio básico Atributos del proceso Atributos de la tarea Atributos del recurso Restricciones de los atributos de los elementos MOS Restricciones de los atributos del servicio compuesto Restricciones de los atributos del servicio básico Restricciones de los atributos del proceso Restricciones de los atributos de la tarea Restricciones de los atributos del recurso Representación gráfica de los atributos en los elementos MOS Representación de los elementos MOS con UML Generación del metamodelo MOS Ecore a partir de UML Elementos del metamodelo MOS Ecore mapeados a elementos WSDL Elementos seleccionados del documento WSDL Elementos del metamodelo MOS Ecore mapeados a elementos BPEL4WS Elementos seleccionados del documento BPEL4WS Capítulo 5 Reglas de transformación Reglas de transformación MOS2WSDL Regla principal MOS2WSDL Reglas de inicio y fin del documento Regla definición del servicio Regla tipos de datos Regla mensajes transportados Subregla tipos de mensajes Subregla elemento petición II

7 Contenido Subregla elemento respuesta Regla lista de operaciones del servicio Subregla operaciones del servicio Regla protocolo y formato de datos Subregla protocolo soap para las operaciones Regla servicio Web Reglas de transformación MOS2BPEL Regla principal MOS2BPEL Reglas de inicio y fin del documento Regla definición del proceso Regla lista de servicios participantes Subregla servicios participantes Regla variables involucradas Subregla variables Regla orquestación de servicios Subregla asignación de valores de las variables Subregla invocación de servicios Capítulo 6 Análisis y diseño del prototipo Diagramas de casos de uso Diagramas de secuencia Diagrama de clases Capítulo 7 Implementación y pruebas Implementación del prototipo Aplicación de las pruebas en el prototipo Descripción de las características probadas Prueba No Prueba No Prueba No Prueba No Prueba No Resultados obtenidos de la ejecución del plan de pruebas Análisis de resultados Conclusiones Aportaciones Trabajo futuro Anexo A Escenarios de los casos de uso Anexo B Diagramas de secuencia Anexo C Descripción de los casos de prueba Referencias III

8 Contenido Índice de figuras Figura 2.1: Modelos de la arquitectura orientada a servicios Figura 2.2: Operaciones fundamentales de un servicio Web Figura 2.3: Estructura del documento WSDL Figura 2.4: Estructura del documento BPEL4WS Figura 4.1: Arquitectura de cuatro niveles [MOF02] Figura 4.2: Metamodelo MOS usando UML Figura 4.3: Metamodelo mos.ecore Figura 5.1: Regla principal MOS2WSDL Figura 5.2: Reglas de inicio y fin Figura 5.3: Regla definitionwsdl Figura 5.4: Regla typeswsdl Figura 5.5: Regla messageswsdl Figura 5.6: Subregla messagestype Figura 5.7: Subregla partsrequest Figura 5.8: Subregla partsresponse Figura 5.9: Regla porttypeswsdl Figura 5.10: Subregla porttypesoperations Figura 5.11: Regla bindingswsdl Figura 5.12: Subregla bindingsoperations Figura 5.13: Regla servicewsdl Figura 5.14: Regla principal MOS2BPEL Figura 5.15: Reglas de inicio y fin Figura 5.16: Regla processbpel Figura 5.17: Regla partnerlinksbpel Figura 5.18: Subregla partners Figura 5.19: Regla variablesbpel Figura 5.20: Subregla variables Figura 5.21: Regla orchestrationbpel Figura 5.22: Subregla assign Figura 5.23: Subregla invoke Figura 6.1: Diagrama general de casos de uso Figura 6.2: Diagrama del caso de uso CU_1 Modelar servicios de una organización Figura 6.3: Diagrama del caso de uso CU_2 Generar modelo MOS Figura 6.4: Diagrama de secuencia del caso de uso CU_1 Modelar servicios de una organización Figura 6.5: Diagrama de secuencia del caso de uso CU_2 Generar modelo MOS Figura 6.6: Paquete de la vista (A) Figura 6.7: Paquete de la vista (B) Figura 6.8: Paquete del control Figura 6.9: Paquete del modelo Figura 7.1: Ventana principal del prototipo Figura 7.2: ModeloPrueba Figura 7.3: ModeloPrueba Figura 7.4: ModeloPrueba Figura 7.5: ModeloPrueba Figura 7.6: ModeloPrueba Figura A.1: Diagrama de actividad del caso de uso CU_ IV

9 Contenido Figura A.2: Diagrama de actividad del caso de uso CU_ Figura A.3: Diagrama de actividad del caso de uso CU_ Figura A.4: Diagrama de actividad del caso de uso CU_ Figura A.5: Diagrama de actividad del caso de uso CU_ Figura A.6: Diagrama de actividad del caso de uso CU_ Figura A.7: Diagrama de actividad del caso de uso CU_ Figura A.8: Diagrama de actividad del caso de uso CU_ Figura B.9: Diagrama de secuencia del caso de uso CU_ Figura B.10: Diagrama de secuencia del caso de uso CU_ Figura B.11: Diagrama de secuencia del caso de uso CU_ Figura B.12: Diagrama de secuencia del caso de uso CU_ Figura B.13: Diagrama de secuencia del caso de uso CU_ Figura B.14: Diagrama de secuencia del caso de uso CU_ Figura C.15: Creación del ModeloPrueba1 en el prototipo de modelado Figura C.16: ModeloPrueba1.mos obtenido en el prototipo Figura C.17: registrarpago.wsdl Figura C.18: encontrarcosto.wsdl Figura C.19: pagolicencia.bpel Figura C.20: XML pagolicencia.bpel Figura C.21: Creación del ModeloPrueba2 en el prototipo de modelado Figura C.22: ModeloPrueba2.mos obtenido en el prototipo Figura C.23: renovardatos.wsdl Figura C.24: tramitarrenovacion.bpel Figura C.25: XML tramitarrenovacion.bpel Figura C.26: Creación del ModeloPrueba3 en el prototipo de modelado Figura C.27: ModeloPrueba3.mos obtenido en el prototipo Figura C.28: checarinventario.wsdl Figura C.29: Creación del ModeloPrueba4 en el prototipo de modelado Figura C.30: ModeloPrueba4.mos obtenido en el prototipo Figura C.31: registrarcliente.wsdl Figura C.32: registrarpago.wsdl Figura C.33: enviaralmacen.wsdl Figura C.34: realizarpago.bpel Figura C.35: XML realizarpago.bpel Figura C.36: Creación del ModeloPrueba5 en el prototipo de modelado Figura C.37: ModeloPrueba5.mos obtenido en el prototipo Figura C.38: registrardireccion.wsdl Figura C.39: eliminardeinventario.wsdl Figura C.40: guiadeembarque.wsdl Figura C.41: prepararenvio.bpel Figura C.42: XML prepararenvio.bpel V

10 Contenido Índice de tablas Tabla 1.1: Comparativa de los trabajos relacionados a esta tesis Tabla 4.1: Selección de elementos MOS Tabla 4.2: Elementos MOS a considerar para representarlos en el metamodelo Ecore Tabla 4.3: Elementos gráficos MOS Tabla 4.4: Correspondencia de elementos MOS a elementos WSDL Tabla 4.5: Correspondencia de elementos MOS a elementos BPEL4WS Tabla 7.1: Resumen del plan de pruebas Tabla A.1: Escenario del caso de uso CU_1 Modelar servicios de una organización Tabla A.2: Escenario del caso de uso CU_1.1 Modelar servicio compuesto Tabla A.3: Escenario del caso de uso CU_1.2 Modelar servicio básico Tabla A.4: Escenario del caso de uso CU_1.3 Modelar procesos Tabla A.5: Escenario del caso de uso CU_1.4 Modelar protocolo Tabla A.6: Escenario del caso de uso CU_2 Generar modelo MOS Tabla A.7: Escenario del caso de uso CU_2.1 Identificar propiedades de los elementos MOS Tabla A.8: Escenario del caso de uso CU_2.2 Guardar información del modelo VI

11 Introducción Actualmente, las empresas pueden verse como entidades proveedoras de servicios a clientes potenciales. En este sentido, un servicio puede definirse como: a) una interacción entre cliente/proveedor; b) la capacidad de un proveedor de servicios para producir un beneficio; c) una aplicación que puede ser accedida sobre la Web, etc [QUAR07]. Ante la enorme competencia de ofrecer un mismo servicio a los usuarios, las empresas buscan la forma de hacer atractivos sus servicios. Una manera novedosa de ofrecer servicios es explotar las actuales tecnologías de información para hacer e-business, es decir, comercio electrónico (los servicios de e-business son tareas de cómputo poco acopladas que se comunican a través de Internet y desempeñan una gran parte de las interacciones business-to-business, B2B). El objetivo de los sistemas e-business es representar los procesos de una empresa a través de Internet. 1

12 Introducción Esta nueva forma de hacer negocios ha forzado el desarrollo de nuevas tecnologías que permitan implementar el comercio electrónico [BIEB05]. Una de estas tecnologías emergentes es la de servicios Web. Un servicio Web puede ser visto como una aplicación modular auto-contenida, auto-descrita, que es publicada, localizada e invocada a través de Internet. La tecnología actual en modelado de servicios [VISU09] [NETB09] se ha enfocado en definir las funcionalidades de los servicios Web y su integración con los sistemas de software existentes. Si bien este enfoque permite dar respuesta clara a qué servicios se ofrecen y cómo se implementan, no permite dar una respuesta al porqué de estos servicios. Por lo tanto, los enfoques actuales no responden las siguientes preguntas por qué se ofrece un determinado servicio?, por qué está diseñado de esa forma?, quiénes son los usuarios potenciales?, el servicio se ofrece de una manera que es aceptable para todos los miembros de su grupo o sólo algunos? [LAUD04]. La incapacidad de responder estas preguntas se deriva de la carencia de fuentes confiables para definir servicios, y más específicamente de la carencia de mecanismos para establecer la correspondencia entre las funcionalidades del negocio y las funcionalidades de los servicios Web. En este sentido, los servicios del mundo real tienen una variabilidad y complejidad que es difícil de representar en servicios Web si no se cuenta con mecanismos adecuados de elicitación de requerimientos. La solución más clara para el problema planteado consiste en establecer una relación de mapeo entre el comportamiento del negocio y los servicios Web que replicarán las funcionalidades de la empresa en la Web [BIEB05]. Existen trabajos que han intentado utilizar modelos de negocios como fuente de diseño de servicios Web [LAUD04]. Sin embargo, la principal problemática de estos enfoques actuales es que se utilizan modelos de negocio puros, basados en aspectos transaccionales del negocio. De esta forma, la transformación de estos modelos puros en servicios Web no es directa, ya que ambos manejan distinto enfoque de representación. En los modelos puros los servicios deben ser identificados dentro de las interacciones sociales entre los actores del negocio, mientras que la representación de los servicios Web es auto-contenida y auto-descrita. Para lograr el mapeo directo entre un modelo de servicios y los servicios Web, proponemos una metodología para la generación de especificaciones WSDL (Web Services Description Language) de servicios Web a partir de modelos de negocio orientados a servicios. Partimos de la hipótesis de que es posible traducir los elementos de modelado de los servicios de negocio en sus correspondientes primitivas de implementación de un lenguaje de definición de servicios como es WSDL. Además de la obtención de un documento para definir el comportamiento del proceso de negocio basado en servicios Web, a través de BPEL4WS (Business Process Execution Language for Web Services). El proceso de generación de las especificaciones utiliza el enfoque MDA (Model Driven Architecture) de tal forma que la correspondencia entre los elementos del modelo de negocio y los servicios Web es dirigida por reglas de transformación. La metodología también se basará en SOA (Service-Oriented Architecture) con la cual se obtendrá un 2

13 Introducción ambiente de servicios que sean interoperables y que puedan ser compuestos para obtener servicios de mayor complejidad. Este trabajo ha sido desarrollado con el fin de que organizaciones (gubernamentales, privadas o académicas) lo usen para exponer los servicios que ofrecen como servicios Web. Los usuarios de la aplicación de esta investigación, serán aquellos que usen los servicios que las organizaciones generen e implementen. La organización del documento de tesis es la siguiente: en el capítulo 1, la sección 1.1 muestra una breve descripción de los antecedentes de esta tesis; la sección 1.2 presenta el planteamiento del problema; la sección 1.3 describe el objetivo a conseguir con esta investigación; la sección 1.4 explica la justificación del trabajo y los beneficios obtenidos; la sección 1.5 describe el estado del arte; y la sección 1.6 los alcances y limitaciones considerados para el desarrollo de la tesis. En el capítulo 2, la sección 2.1 presenta la definición de la arquitectura dirigida por modelos y describe brevemente la transformación de modelos; la sección 2.2 describe la técnica de modelado de negocios Tropos; la sección 2.3 presenta la descripción del modelado organizacional orientado a servicios; la sección 2.4 explica la definición de servicios Web; la sección 2.5 explica las descripciones WSDL de los servicios Web; y la sección 2.6 define y describe el lenguaje BPEL4WS. En el capítulo 3, la sección 3.1 explica el lenguaje de restricción de objetos OCL; la sección 3.2 presenta los lenguajes de transformación analizados en esta investigación; mientras que la sección 3.3 explica y describe el lenguaje de transformación usado. En el capítulo 4, la sección 4.1 describe el metamodelo MOF; la sección 4.2 explica como es la arquitectura de cuatro niveles; la sección 4.3 presenta una descripción breve de los metamodelos analizados para crear el metamodelo específico de dominio usado en este trabajo; la sección 4.4 explica el metamodelo EMF Ecore seleccionado para crear el metamodelo específico de dominio; y la sección 4.5 presenta la descripción del metamodelo de dominio específico MOS creado en este trabajo de investigación y que será el metamodelo intermedio usado para realizar la transformación. En el capítulo 5, la sección 5.1 presenta las reglas de transformación de MOS a WSDL; y la sección 5.2 presenta las reglas de transformación de MOS a BPEL. En el capítulo 6 se presenta el análisis y diseño del prototipo, la sección 6.1 muestra los diagramas de casos de uso; la sección 6.2 presenta los diagramas de secuencia; y la sección 6.3 presenta el diagrama de clases del prototipo. En el capítulo 7, la sección 7.1 describe la forma en que se implementó el prototipo así como la explicación de la interfaz; la sección 7.2 presenta la descripción de la aplicación del plan de pruebas; y la sección 7.3 presenta los resultados obtenidos de la ejecución de las pruebas. Por último se presentan las conclusiones finales generadas con el desarrollo de este trabajo de investigación, las aportaciones logradas así como la descripción del trabajo futuro. 3

14 Capítulo 1 Antecedentes 1.1 Antecedentes Debido a los nuevos desafíos que presentan las organizaciones a partir del crecimiento de las tecnologías de información, éstas se ven en la necesidad de ir a la par en la evolución de la tecnología. Es entonces cuando aparece e-business como un catalizador de los cambios organizacionales para adaptarse a los nuevos retos de negocios [DIMA06]. Actualmente, las organizaciones operan en ambientes heterogéneos, competitivos y de cambio, donde los servicios Web son utilizados para implementar sus procesos de negocio y de esta manera permanecer en el mercado. Por lo tanto, hay diferentes enfoques que intentan dar soporte a esta implementación de procesos. Existen trabajos que se enfocan en la representación de servicios a nivel de negocio pero que no involucran necesariamente la generación de servicios Web. A continuación se mencionan algunos trabajos como antecedentes a este proyecto de tesis. 4

15 Capítulo 1 Antecedentes A service-oriented approach for the i* Framework [ESTR08] En este trabajo se explora el uso de una arquitectura orientada a servicios para mejorar la representación de conocimiento en el Framework Tropos. Actualmente, uno de los principales problemas del Framework Tropos es que todos los elementos de modelado son colocados en el mismo diagrama sin referencias a su nivel de abstracción. Esto ocasiona modelos Tropos spaghetti donde no existe granularidad ni refinamiento. La propuesta de este trabajo consiste en utilizar los servicios de negocio como bloques de construcción que encapsulan un cierto comportamiento organizacional. De esta forma, el proceso de modelado de negocios inicia con la identificación de los servicios de alto nivel ofrecidos a clientes potenciales y continúa con la asociación entre los servicios de negocio y las metas de la organización. Una vez realizado este procedimiento, se detallan los procesos de negocio necesarios para implementar cada servicio. Finalmente, cada proceso es descrito utilizando el lenguaje de modelado Tropos Impact of service orientation at the business level [CHER05] En este trabajo se enfatiza la necesidad de establecer un vínculo estrecho entre la estrategia del negocio y la tecnología de información. Por lo que, en este trabajo se proponen los siguientes elementos: 1. Una vista estructurada de un negocio que facilite su análisis estratégico y operacional. 2. Un método riguroso para traducir esta vista del negocio estructurada al marco apropiado de tecnología de información (orientada a servicios). 3. Nuevas tecnologías de construcción y ejecución adaptadas al nuevo marco de tecnología de información. El entendimiento del negocio orientado a servicios depende de la efectividad en la captura de las características de ejecución del negocio. IBM ha dado solución a cada uno de los puntos citados anteriormente con el desarrollo de: 1) CBM (el modelo de componentes de negocio), el cual es un método para crear una vista del negocio y después explorar oportunidades para la transformación; 2) SOMA (arquitectura y modelado orientado a servicios) para mapear la estructura del negocio al marco de tecnología de información; 3) tecnologías de construcción y ejecución necesitadas para soportar soluciones SOA e-service Design Using i* and e 3 value Modeling [JAAP06] En este trabajo se aplican técnicas sistemáticas de ingeniería de requerimientos para el modelado de metas y valores, estas técnicas ayudan al analista a crear, representar y analizar modelos de negocio e-service. A través del uso de un modelo i* se exploran las metas estratégicas de la empresa y con el modelo e 3 value se valora cómo estas metas pueden resultar en servicios beneficiosos para la empresa. 5

16 Capítulo 1 Antecedentes La técnica e 3 value indaga sobre aquello que las empresas intercambian y que tiene un valor económico. Esto podría resultar en un modelo de valor del negocio, mostrando claramente a la empresa y a los clientes finales involucrados y el flujo de los objetos de valor (bienes, servicios y dinero). Lo que se busca al aplicar estas dos técnicas (i* y e 3 value) es obtener un modelo de negocio aceptable para todos los actores, que cumplan con sus metas y que sean beneficiosos tanto para la empresa como para los clientes; además, se busca exponer aquellos servicios electrónicos que cumplirán con las metas y con el beneficio esperado. 1.2 Planteamiento del problema En la actualidad, las técnicas de elicitación de requerimientos utilizadas como fuente para la generación de servicios Web carecen de confiabilidad, ya que sólo se enfocan en definir las funcionalidades [VISU09] [NETB09] [ECLI09] [IBM09] [ORAC09]. Estas técnicas no aseguran la igualdad entre las funcionalidades de un servicio de negocio contra los servicios Web, debido a que no representan un origen claro que considere las metas y/o necesidades de los actores del negocio. Los servicios Web que se obtienen a partir de las técnicas actuales pueden ser eficientes y llevarse a cabo con éxito, pero pueden no satisfacer realmente lo que el cliente desea. Es por esta razón que resulta importante el conocer las metas del cliente (actor del negocio) para ofrecer un servicio Web que cumpla con sus requerimientos y que además se realice con éxito. Por lo tanto, el problema es que no existen mecanismos para asegurar que los servicios Web existentes cumplen exactamente con las funcionalidades de un servicio de negocio. En esta propuesta planteamos que los modelos de negocio orientados a servicios ofrecen una buena fuente para la generación de servicios Web. 1.3 Objetivo Como ya se comentó, unas de las problemáticas en la tecnología orientada a servicios es la falta de fuentes confiables para determinar servicios Web. El objetivo general de este proyecto es el desarrollo de una metodología para generar especificaciones WSDL de servicios Web a partir de modelos de negocio orientados a servicios. La metodología propuesta considera un enfoque MDA (Model Driven Architecture) para asegurar la precisión en la transformación entre modelos. Los modelos de negocio orientados a servicios representan a los servicios con funciones bien definidas, auto-contenidos y con la propiedad de granularidad (estas son características que comparten con los servicios Web). La versión del Framework Tropos 6

17 Capítulo 1 Antecedentes con la que se trabaja, es una orientada a servicios [ESTR08] y se valora la pertinencia de utilizar modelos de negocios basados en servicios para generar servicios Web. Además, la representación explícita de metas en el Framework Tropos permite definir el porqué de cada uno de los servicios Web y el porqué cada servicio ha sido implementado de una cierta forma. 1.4 Justificación y beneficios Justificación La tecnología de información orientada a servicios va en aumento siendo, hoy en día, el motor de crecimiento de muchas empresas. Para el 2008, la arquitectura orientada a servicios será una práctica de ingeniería de software dominante, finalizando con los 40 años de dominación de la arquitectura de software monolítica [NATI03]. Sin embargo, a pesar del impacto de los servicios Web, no todos los aspectos relativos a su creación han sido resueltos por la tecnología actual. Uno de estos aspectos no resueltos, y que pudiera ser uno de sus factores claves, es la carencia de trabajos que proporcionen un origen claro de cada servicio implementado. Esta carencia imposibilita a los analistas a determinar si la funcionalidad de los servicios corresponde realmente con las tareas del negocio. Dentro de las técnicas de elicitación de requerimientos que son usadas comúnmente como fuente para la generación de servicios Web se pueden mencionar: casos de uso, modelos de clases y diagramas de actividad de UML. Estas técnicas permiten generar servicios Web que desempeñan todas las operaciones especificadas, pero no se puede saber si cumplen con las metas del negocio, ya que estas técnicas resuelven el problema desde el punto de vista del usuario, con los requerimientos que éste desea y con los procesos que éste debe llevar a cabo. En esta propuesta de tesis proponemos establecer un origen claro de los servicios Web con base en los elementos clave de un modelo de negocio, como son: metas, dependencias entre actores, tareas, etc. Por lo tanto, se propone un método de transformación que establezca una relación clara de mapeo entre las funcionalidades actuales del negocio y su puesta en marcha a través de los servicios Web. Beneficios Para lograr una representación clara de los servicios Web se debe contar con una fuente confiable que determine la funcionalidad de éstos. Las ventajas de utilizar una fuente confiable para la generación de servicios son las siguientes: a) se incrementa la trazabilidad entre el modelo de negocio y los servicios Web; b) es posible conocer si los servicios a exponer satisfacen las metas de los actores del negocio; c) se da una mayor flexibilidad de 7

18 Capítulo 1 Antecedentes hacer cambios en los procesos de negocio y obtener el nuevo servicio que lo cubrirá; d) ahorro de tiempo y esfuerzo al expandir la empresa bajo nuevos ambientes de negocio, e) se puede contribuir con principios de diseño que puedan ser útiles para el diseño de servicios Web a partir de servicios de negocio. Una de las ventajas que es importante remarcar es la flexibilidad al minimizar los efectos de crear nuevos servicios, reutilizando los existentes y adaptarlos rápidamente a nuevas condiciones de mercado, como son por ejemplo: los cambios de región, leyes, normas, políticas, etc. Es decir, si el costo del servicio se ve afectado por el cambio de región no es necesario crear un nuevo servicio sólo se necesitaría modificar la cantidad anterior por la nueva. Otro ejemplo de reutilización de un servicio existente puede ser por el cambio de leyes, si el servicio debe contar con nuevas restricciones se realizaría una extensión del servicio sin necesidad de volver a crearse. 1.5 Estado del arte Los trabajos relacionados con este proyecto se pueden clasificar en dos categorías: de modelado de servicios Web y de generación de servicios Web. Algunos de los trabajos cuyo enfoque es el modelado de servicios Web hacen uso de UML, ya sea en su forma pura o haciendo extensiones para poder representarlos en su descripción WSDL. En otros, el modelado se hace a partir de procesos de negocio usando metodologías como Tropos, BPMN (Business Process Modeling Notation) entre otros. Otros trabajos sólo hacen una representación en UML del servicio Web de forma aislada para su equivalencia en WSDL, aplicando MDA en el proceso de transformación. De los trabajos que en su investigación presentan una generación de servicios Web, algunos se basan en el enfoque dirigido por modelos para el desarrollo de sus reglas de transformación y también proponen la generación de descripciones de servicios Web de forma automática o semi-automática. A continuación se muestra una breve descripción de los trabajos relacionados Designing Web Services with Tropos [LAUD04] En este trabajo se propone una metodología para diseñar servicios Web. La metodología está fundada en Tropos, una técnica de desarrollo de software orientada a agentes y soporta el análisis de requerimientos tempranos y tardíos, también el diseño arquitectural y detallado. La idea clave de esta metodología es que los servicios de software son diseñados iniciando con las metas de los stakeholder y analiza estas metas para definir el espacio de soluciones alternativas. El diseño del servicio Web se obtiene a partir de la identificación de las capacidades de los agentes en el modelo y se recurre a diagramas de actividades para describir los 8

19 Capítulo 1 Antecedentes eventos que suceden para cada agente de acuerdo a sus capacidades y a diagramas de secuencia para modelar la comunicación entre los agentes. Al final del proceso de diseño se pueden utilizar estándares abiertos para la implementación de los servicios Web. Estos estándares son: WSDL para la descripción de un servicio Web; SOAP para las llamadas/respuestas de procedimientos remotos; y UDDI para describir y descubrir servicios Web Design Methodology for Web Services and Business Processes [PAPA02] En este trabajo se presenta una metodología de diseño para servicios Web y procesos de negocio. Se plantea cómo deben describirse los procesos de negocio con el objetivo de que los servicios puedan ser fácilmente identificados. Se proporcionan estrategias y principios que consideran aspectos funcionales y no funcionales del diseño de servicios Web. La metodología propuesta está basada en el núcleo de la infraestructura del servicio Web. Consiste de dos partes: la primera parte es un marco para el análisis del proceso de negocio y la segunda son los principios de diseño del servicio. El marco proporciona el medio para identificar los servicios Web y sus relaciones; los principios dan las pautas para el diseño del servicio Web tanto de las perspectivas funcionales como las no funcionales. El primer paso en la metodología de diseño del servicio es determinar los objetivos y las funciones del proceso de negocio así como también describir la estructura del negocio. El segundo paso es identificar las responsabilidades asociadas con las actividades del proceso de negocio e identificar los proveedores del servicio que son responsables de llevarlas a cabo. Una vez que la metodología de diseño del servicio Web ha sido aplicada, la especificación del servicio Web en WSDL puede seguir los siguientes pasos: 1) especificar la interfaz del servicio; 2) crear los parámetros de operación; 3) mensaje y transporte; 4) implementación Model Driven Design of Web Service Operations using Web Engineering Practices [RUIZ07] Este trabajo presenta una guía de diseño de servicios Web que extiende el método OOWS. Este método es un método de ingeniería Web que está basado en los principios definidos por el Desarrollo Dirigido por Modelos (MDD). El método OOWS permite obtener automáticamente aplicaciones Web completamente funcionales a partir de modelos conceptuales. Las contribuciones principales del trabajo son las siguientes: a) determinar cuales modelos son útiles para obtener operaciones de servicios Web; b) proponer una guía metodológica para diseñar las operaciones de los servicios Web; c) identificar operaciones que dan soporte a los requerimientos funcionales de una aplicación; d) proporcionar un 9

20 Capítulo 1 Antecedentes método de diseño de servicios Web con una herramienta para ayudar a generar automáticamente el WSDL del servicio Web. El proceso de diseño de servicios Web es definido a partir de las siguientes disciplinas: elicitación de requerimientos, modelado conceptual de OO-Method y OOWS y generación de código. Una de las formas en que identifica las operaciones del servicio es con base al modelo de requerimientos. En este modelo se define una taxonomía de tareas, las cuales son descompuestas en subtareas. Las operaciones detectadas en el diagrama de tareas pueden ser vistas como las operaciones públicas que debe ofrecer el servicio. Otra de las formas de identificar las operaciones es a partir de los modelos conceptuales de OOWS ( modelos de usuarios, navegación y presentación). La herramienta que genera automáticamente la especificación WSDL es ITOW, tomando como entrada un archivo XML donde los modelos OO-Method y OOWS están almacenados Model-driven Web Service Development [GRØN04] Este trabajo recomienda un proceso dirigido por modelos para el desarrollo de servicios Web, combinando el lenguaje de modelado gráfico UML con WSDL. La principal contribución que se hace es una estrategia de modelado puro UML soportada por la implementación de reglas de conversión de dos vías entre los modelos UML y los documentos WSDL. Este artículo investiga el uso de UML para expresar el contenido y comportamiento de los servicios Web de una manera más entendible que el documento WSDL. Este enfoque es motivado por la arquitectura dirigida por modelos (MDA). Los autores de este trabajo suponen que, tanto el enfoque de modelado UML puro como las reglas de conversión adecuadas entre UML y WSDL ayudan a la comprensión y son suficientes para realizar una ingeniería de dos vías entre UML y WSDL para los servicios Web. El proceso de desarrollo de servicios Web dirigido por modelos sigue los siguientes pasos: 1. Descubrimiento de servicios Web candidatos. 2. Conversión de las descripciones de los servicios Web a UML por medio de una transformación de ingeniería inversa, con el supuesto de que es más fácil entender modelos UML de la interfaz del servicio Web que entender los documentos WSDL. 3. A través de una herramienta UML se revisan e integran los modelos importados para formar un nuevo modelo de un servicio Web compuesto. Este paso se 10

21 Capítulo 1 Antecedentes compone de dos sub-actividades, modelado de la interfaz y modelado del flujo de trabajo. La salida de este paso es un nuevo modelo UML representando el nuevo servicio Web compuesto con sus interfaces y su flujo de trabajo. 4. El modelo UML del paso anterior es usado para generar la descripción WSDL. Para la transformación de UML a WSDL, las reglas de conversión que aplican son de modelos UML independientes de WSDL. Los modelos UML independientes de WSDL no contienen ninguna información sobre bindings, transport protocol y access URLs. Para obtener un documento WSDL completo, estas propiedades necesitan ser agregadas a la especificación WSDL Automatic Generation from UML Models in a MDA Framework [VARA05] Este trabajo propone una extensión a UML para WSDL y hace uso de un subsistema MIDAS-CASE para servicios Web. El subsistema de servicios Web usa la extensión del lenguaje UML para WSDL pensado para soportar el modelado de servicios Web con el UML extendido y la generación automática de la respectiva descripción del servicio Web en el estándar WSDL. La extensión UML para WSDL y la herramienta CASE son parte del subsistema MIDAS, un framework metodológico dirigido por modelos para el desarrollo ágil de Sistemas de Información Web que propone el uso de estándares a través de todo el proceso de desarrollo. Para aplicar MDA al desarrollo de un servicio Web y obtener un proceso de desarrollo correcto y completo, es preferible la definición de un PIM inicial. La siguiente etapa consiste en aplicar transformaciones subsecuentes al PIM para obtener el PSM que incluirá sólo conceptos en el alcance del servicio Web. Finalmente con el PSM, el código que implementa el servicio Web o su descripción WSDL será generado automáticamente. MIDAS propone por un lado especificar el sistema entero mediante Modelos Independientes de Cómputo (CIMs), Modelos Independientes de Plataforma (PIMs) y Modelos Específicos de Plataforma (PSMs); y especificar las reglas de mapeo entre estos modelos. Además, MIDAS sugiere usar UML como notación única para modelar tanto PIMs como PSMs. Este trabajo hace una representación de WSDL a través del UML extendido. En este trabajo se define además un conjunto de estereotipos, valores etiquetados y restricciones que permiten representar WSDL en una notación gráfica usando UML. El modelo UML extendido es almacenado en algún formato XML y a través de un parser se obtiene el documento WSDL. 11

22 Capítulo 1 Antecedentes Generación de Aplicaciones Web Basadas en Procesos de Negocio Mediante Transformación de Modelos [TORR07] En este trabajo se ha definido una extensión al modelo navegacional (MN) de OOWS que permite modelar las interfaces gráficas que son necesarias para permitir la interacción entre humanos y los procesos de negocio. Esta investigación proporciona una metodología para la generación automática de aplicaciones Web que den soporte a la ejecución de procesos de negocio (PNs). Para conseguir el objetivo proponen generar de forma automática la interfaz de usuario a partir de una especificación del proceso de negocio. La interfaz generada permite a los usuarios llevar a cabo las actividades que forman parte del proceso. Primero se tiene que modelar el espacio del problema en el Modelo de Procesos de Negocio (MPN), mediante una notación gráfica que describe la secuencia de tareas que se deben realizar. Algunas de la tareas definidas en el proceso requieren de una interfaz de usuario para ser realizadas. Las interfaces de usuario se definen en el Modelo Navegacional (MN). La relación entre el MPN y el MN se establece a partir de la definición del PN, y tras aplicar un conjunto de transformaciones, se obtiene la parte del MN que dará soporte a la ejecución de los procesos (transformación modelo a modelo). Posteriormente, una vez definido completamente el MN y tras una nueva transformación de modelo a texto se obtienen las interfaces de usuario representadas en una tecnología concreta. Para lograr la transformación de modelo a modelo se identifican las primitivas del MN y se establecen las reglas de transformación para generar los MNs a partir de la especificación de un PN Applying MDA Approach for Web Service Platform [BEZI04] Este trabajo presenta el desarrollo de un ejemplo de e-business basado en dos aplicaciones diferentes del enfoque MDA. En la primera aplicación el modelo PIM es creado usando UML. Este modelo PIM es transformado usando el Lenguaje de Transformación Atlas (ATL) para generar el modelo PSM basado en tres plataformas objetivo : Java, Web Service y Java Web Service Developer Pack (JWSDP). En la segunda aplicación, el PIM es creado usando Enterprise Distributed Object Computing (EDOC) y transformado en otro PSM basado en los mismas plataformas objetivo que el anterior. Para realizar el mapeo de PIM a PSM se determinan los elementos equivalentes entre cada uno de los modelos. La transformación del modelo es realizada por un motor que ejecuta reglas de transformación. Las reglas de transformación especifican como generar un modelo objetivo (PSM) a partir de un modelo fuente (PIM). 12

23 Capítulo 1 Antecedentes De acuerdo al enfoque MDA, los modelos fuente (PIM) y objetivo (PSM) deben ser meta-modelos, modelos, por lo que en este trabajo hacen la representación en UML del modelo PSM. Después de identificar los elementos equivalentes entre UML y el meta-modeldescriben las reglas de transformación a través de ATL. PSM, Análisis comparativo Algunos de los trabajos relacionados que han sido considerados en el estado del arte contemplan los mismos aspectos a desarrollar en este trabajo. La diferencia reside en el uso de diferentes estrategias de modelado. Es importante acentuar que la estrategia a usar puede ser un elemento clave para obtener el resultado esperado, en este caso la especificación del servicio Web. La hipótesis que se plantea es la posibilidad de traducir los elementos de modelado de los servicios de negocio en sus correspondientes primitivas de implementación de un lenguaje de definición de servicios como es WSDL. Trabajo [LAUD04] [PAPA02] [RUIZ07] [GRØN04] [VARA05] [TORR07] [BEZI04] Tesis Tabla 1.1: Comparativa de los trabajos relacionados a esta tesis Estrategia de modelado Tropos Especificación a partir de procesos de negocio Método de modelado OOWS UML puro Extensión UML Método de modelado OOWS 3 UML/EDOC Enfoque orientado a servicios para el framework i* Aplicación de MDA 1 4 Generación de reglas de transformación Composición de servicios Web 2 Resultado Metodología para diseñar servicios Web Metodología para diseñar servicios Web Herramienta ITOW Uso de herramienta UMT de OMG Herramienta MIDAS-CASE Uso de herramienta Borland Together Architect 2006 for Eclipse Uso de herramienta ATL Metodología y prototipo 1 Basado en principios definidos por MDD (Model-Driven Development) 2 A partir de varios modelos UML de las descripciones WSDL genera una sola descripción WSDL 3 Extensión al modelo navegacional de OOWS para modelar los interfaces gráficos 4 Ídem 1 13

24 Capítulo 1 Antecedentes Con base en la tabla comparativa, se observan dos trabajos que cumplen con las mismas características que este trabajo de tesis. Los trabajos [TORR07] y [GRØN04] presentan aplicación de MDA en el desarrollo, generan reglas de transformación y hacen composición de servicios. Sin embargo, el trabajo [TORR07] está enfocado al desarrollo de aplicaciones web, que hacen uso de servicios Web, pero su enfoque está dirigido al desarrollo de aplicaciones con base a la transformación de modelos. Por otra parte, el trabajo [GRØN04] tiene como principal contribución el de presentar los documentos WSDL como un modelo de UML puro, sin hacer extensiones. La investigación se centra más en hacer notar que el modelado de los servicios Web puede llevarse a cabo usando UML y que se pueden aplicar reglas de transformación de dos vías para pasar de UML a WSDL. Esto sin tomar en cuenta todo el contexto que envuelve a un servicio Web. 1.6 Alcances y limitaciones Alcances El modelo de negocios orientado a servicios cuenta con procesos que pueden ser automatizados. Los servicios que son modelados son factibles para desglosarce en procesos. El modelo de negocios orientado a servicios ha sido adaptado, para que las primitivas de modelado permitan obtener los servicios Web a través de la transformación. Se construyó un prototipo que permite realizar un modelo en base a lo investigado en este trabajo. Es importante señalar que no se está proponiendo un método de modelado de negocios orientado a servicios. El método existente [ESTR08] se usó como modelo fuente. El método de modelado cuenta con un modelo de procesos que detalla secuencialmente las tareas de cada servicio. Por lo cúal, se plantea que este modelo puede establecer la coordinación de los servicios Web que se generarán. Es decir, este modelo de procesos es la fuente para determinar el documento BPEL4WS que describirá la forma de interacción de los servicios Web. Las organizaciones que pueden usar este trabajo de tesis pueden ser gubernamentales, privadas y académicas. 14

25 Capítulo 1 Antecedentes Lo usuarios serán aquellos que utilicen los servicios expuestos por las organizaciones que implementen este trabajo de investigación. Limitaciones Se obtienen los documentos WSDL correspondientes a cada servicio Web. Estos documentos describen las operaciones de cada servicio y cómo son accedidos. No se genera la implementación ejecutable de los servicios Web en ningún lenguaje de programación como: Java, C#, C++, etc. Se obtiene un documento BPEL4WS que describe la forma de interacción entre los servicios Web. Tanto WSDL como BPEL4WS están apoyados en XML, por lo que los documentos de cada uno están descritos bajo este lenguaje. 15

26 Capítulo 2 Marco teórico En este capítulo se describen: el enfoque MDA, la técnica de modelado de negocios Tropos, el modelado organizacional orientado a servicios, los servicios Web, la especificación WSDL de servicios Web y el lenguaje BPEL4WS. Los cuales son temas que respaldan el trabajo de investigación realizado en esta tesis. 2.1 Arquitectura Dirigida por Modelos MDA En el año 2001 la OMG (Object Managment Group) adopta a la arquitectura dirigida por modelos (Model Driven Architecture, MDA) como un enfoque para usar modelos en el desarrollo de software [OMG03]. MDA establece una separación entre el modelado y los detalles de implementación, haciendo una distinción entre modelos independientes de plataforma (Platform Independent Model, PIM) y modelos específicos de plataforma (Platform Specific Model, PSM). 16

27 Capítulo 2 Marco teórico El modelo PIM expresa el comportamiento o funcionalidad de un sistema, el modelo PIM es un modelo que no tiene ninguna información de implementación sobre una tecnología específica. El modelo PSM especifica detalles de implementación como: lenguaje de codificación, tipos de datos, etc. Las técnicas de transformación convierten modelos independientes de plataforma que especifican las operaciones de los sistemas, en modelos específicos de plataforma [METH03]. Una especificación MDA completa consiste de un modelo base PIM más uno o más modelos PSM y un conjunto de definiciones de interfaz. Cada una de las interfaces describen como el modelo base es implementado en una plataforma middleware diferente. Una de las tecnologías clave usada por MDA para definir los modelos fuente (PIM) y objetivo (PSM) es MOF (Meta-Object Facility) [MOF02]. Éste último es un lenguaje de metamodelado que permite crear metamodelos de dominio específico Transformación de modelos En MDA una de las características que tiene este enfoque es la noción de transformación, la cual se compone de un conjunto de reglas y técnicas usadas para modificar un modelo y conseguir otro modelo [OMG01]. Se pueden realizar diferentes transformaciones, como: PIM a PIM: esta transformación es usada cuando los modelos son refinados, filtrados o especializados durante el desarrollo de ciclo de vida. PIM a PSM: esta transformación es usada cuando el PIM es suficientemente refinado para ser proyectado en la infraestructura de ejecución. La proyección está basada en las características de la plataforma. PSM a PSM: esta transformación se necesita para la realización de componentes e implementación. El mapeo de PSM a PSM está relacionado generalmente al refinamiento de modelos dependientes de plataforma. PSM a PIM: esta transformación es requerida para abstraer modelos de implementaciones existentes en un tecnología particular en un modelo independiente de plataforma. Idealmente, el resultado de este mapeo se comparará con el mapeo de PIM a PSM. 2.2 Técnica de modelado de negocios Tropos Tropos es derivado del griego τροποσ lo cual significa la manera de hacer las cosas [TROP06]. Es una metodología de desarrollo de software orientada a agentes, la cual está basada en los conceptos de requerimientos basados en metas. La metodología Tropos está orientada a soportar todas las actividades de análisis y diseño en el proceso de desarrollo de software. Tropos abarca desde la actividad de análisis 17

28 Capítulo 2 Marco teórico del dominio de la aplicación (permitiendo un entendimiento profundo del ambiente donde el software se utilizará) hasta llegar a la implementación del sistema [BRES04]. La metodología Tropos cuenta con cinco fases de desarrollo: Requerimientos tempranos: se refiere al entendimiento de un problema mediante el estudio de su entorno organizacional. Requerimientos tardíos: el sistema a desarrollar es descrito dentro de su ambiente operacional, junto con las funciones y cualidades relevantes. Diseño arquitectural: la arquitectura global del sistema está definida en términos de subsistemas, interconectados a través de datos, control y otras dependencias. Diseño detallado: el comportamiento de cada componente está definido detalladamente. Implementación: en esta etapa se sigue paso a paso la especificación del diseño detallado en base al mapeo establecido entre los términos de la plataforma de implementación y los conceptos del diseño. Tropos enfatiza la fase del análisis de los requerimientos tempranos que precede a la especificación de los requerimientos tardíos, lo que significa que el desarrollador puede identificar el dominio de los stakeholders (interesados) y modelarlos como actores sociales. Una vez que los actores han sido identificados, se tiene conocimiento de las dependencias de un actor para lograr las metas, cuáles son los planes a ser realizados y qué recursos serán suministrados. Mediante la definición clara de estas dependencias es posible capturar las razones del porqué un sistema de software es desarrollado. El resultado puede ser verificado analizando si la implementación final concuerda con las necesidades iniciales [BRES04]. Los modelos en Tropos se basan en los siguientes conceptos / relaciones: Actor: modela una entidad que tiene metas estratégicas e intencionalidad dentro del sistema o el entorno organizacional. Un actor representa un agente físico, social o de software también como un rol o posición. Meta: representa los intereses estratégicos de un actor. Hay metas duras y metas suaves. Las metas duras son satisfechas mientras que las metas suaves no tienen una definición clara y/o criterio para decidir si se satisfacen o no y con frecuencia son utilizadas para modelar requerimientos no funcionales. Plan: representa la manera de hacer algo de una forma abstracta. La ejecución del plan puede ser un medio para satisfacer una meta o para satisfacer una meta suave. 18

29 Capítulo 2 Marco teórico Recurso: representa una entidad física o de información. Dependencia social: una dependencia social es una relación entre dos actores donde un actor (depender) depende de otro actor (dependee) para conseguir un dependum, que puede representar el logro de una meta, la ejecución de un plan o la entrega de un recurso. Al mismo tiempo, el depender es vulnerable, ya que si el dependee falla en la entrega del dependum, el depender sería afectado en el logro de sus metas. Capacidad: representa la habilidad de un actor para definir, seleccionar y ejecutar un plan para el cumplimiento de una meta. Creencia: representa el conocimiento que el actor tiene del mundo. 2.3 Modelado organizacional orientado a servicios Arquitectura orientada a servicios SOA Una arquitectura orientada a servicios es un enfoque o estrategia en la cual las aplicaciones hacen uso de servicios disponibles en una red [EDOR05]. SOA es actualmente la arquitectura conceptual más popular para la industria de tecnologías de la información. Es en esencia una arquitectura que está diseñada para obtener un ambiente de servicios de red que sean interoperables y puedan ser compuestos, lo cual se presta para crear aplicaciones de una forma dinámica. Esta arquitectura abstrae los servicios de su realización usando el concepto de interfaz, la cual describe cómo ocurrirá la interacción entre las partes. El aspecto más importante de la arquitectura orientada a servicios es que separa la implementación de la interfaz; en otras palabras, separa el qué del cómo [BREN07]. La arquitectura orientada a servicios define tres roles principales que los componentes pueden desempeñar (un productor del servicio, un consumidor del servicio y un agente del servicio), también define las funciones que dan soporte a estos roles. Un productor del servicio es un componente que expone una interfaz del servicio para otro componente que tiene que ejecutar un conjunto de tareas. El productor del servicio puede representar una interfaz del servicio para un sistema reusable o más en general a una interfaz de servicio para un proceso de negocio. Un consumidor del servicio es un componente que descubre e invoca otros servicios, usando las interfaces del servicio expuestas para proporcionar una solución de negocio. El componente consumidor del servicio representará usualmente un componente de la aplicación que invoca funciones soportadas por diferentes componentes productores del servicio. El agente del servicio es un componente que actúa como un facilitador entre los productores del servicio y los consumidores [BREN07]. 19

30 Capítulo 2 Marco teórico Modelo organizacional orientado a servicios La propuesta de este trabajo [ESTR08], es la representación de un modelo organizacional como una composición de servicios de negocio, los cuales representan las funcionalidades que la organización ofrece. Bajo esta propuesta, los servicios de negocio son bloques de construcción básica que permiten representar un modelo de negocios en una arquitectura conceptual de tres niveles. Los niveles relacionados jerárquicamente son: servicios de negocios, procesos de negocio y protocolos de negocio; los tres niveles integran la arquitectura orientada a servicios. El proceso de modelado organizacional empieza con la definición de la vista de alto nivel de los servicios ofrecidos y demandados por la organización. A continuación cada servicio de negocios es refinado en modelos de procesos más concretos de acuerdo al método de servicio de negocio presentado en este trabajo. A través de este enfoque la actividad de modelado difiere respecto al punto de vista en el cuál se modela el ambiente organizacional. Anteriormente, el modelado se centraba en la perspectiva del actor cambiando a una perspectiva del servicio. La arquitectura de servicios de negocio está compuesta de tres modelos que muestran una visión de la empresa (figura 2.1). Lo que la empresa ofrece a su ambiente y lo que obtiene a cambio. Modelo global. En el método propuesto, el proceso de modelado organizacional comienza con la definición de una vista de alto nivel de los servicios ofrecidos y usados por la empresa. El modelo global permite la representación de los servicios de negocio y los actores que representan los roles de proveedor y solicitante. Las extensiones a las primitivas conceptuales de i* son usadas en este modelo. Modelo de proceso. Un servicio de negocio debe ser descompuesto en un conjunto de procesos concretos que lo lleven a cabo. El modelo de procesos hace posible representar las abstracciones funcionales de los procesos de negocio para un servicio específico. Este modelo proporciona los mecanismos requeridos para describir el flujo de múltiples procesos. Este modelo propone extensiones a las primitivas conceptuales de i*. Modelo de protocolo. La semántica de los protocolos y las transacciones de cada proceso de negocio es representada en un diagrama aparte usando las construcciones conceptuales i*. Este modelo proporciona una descripción de un conjunto de actividades estructuradas y asociadas que producen un resultado específico o un producto para un servicio de negocio. Este modelo es representado usando la redefinición de las primitivas de modelado i*. Los elementos usados en el modelo de protocolo corresponden a las metas, tareas y recursos. 20

31 Capítulo 2 Marco teórico Modelo global Modelo de proceso Modelo de protocolo Figura 2.1: Modelos de la arquitectura orientada a servicios. El enfoque propuesto permite al analista reutilizar la definición de protocolos mediante el aislamiento de la descripción de los procesos en diagramas separados. De esta forma, el modelo de procesos representa una vista de los procesos necesitados para satisfacer un servicio pero sin dar detalles de su implementación. Cada proceso de negocio está detallado a través de un protocolo de negocio. La descripción detallada de los procesos está en el modelo de protocolo. Es importante indicar que cada proceso de negocio debe ser refinado en un modelo concreto mediante el uso de la notación i* [ESTR08]. 2.4 Servicios Web Los servicios Web son aplicaciones modulares auto-contenidas y auto-descritas que pueden ser publicadas, localizadas e invocadas a través de Internet. Una arquitectura de servicios Web requiere de tres operaciones fundamentales (ver figura 2.2): publicar, encontrar y enlazar. El proveedor del servicio publica servicios para un agente de servicio. El solicitante de servicios encuentra los servicios requeridos usando a un agente y se enlaza a éstos [IBMW00]. Figura 2.2: Operaciones fundamentales de un servicio Web 21

32 Capítulo 2 Marco teórico Un servicio Web proporciona funcionalidad a las aplicaciones remotas y sitios Web, mediante el intercambio de archivos XML y datos binarios [LOUG02]. El mecanismo de descripción del servicio es uno de los elementos clave en una arquitectura de servicios Web. Los servicios Web se apoyan de estándares para llevar a cabo sus operaciones, estos estándares son: WSDL (Web Services Description Language): el lenguaje es usado para describir un servicio Web en términos de sus puertos (direcciones que implementan este servicio), tipos de puerto (definición abstracta de las operaciones e intercambio de mensajes) y uniones (definición concreta de cuales protocolos son usados para interconectar dos puntos finales que se comunican) [PAPA03]. UDDI (Universal Description, Discovery and Integration): que define una interfaz programática para publicación (API de publicación) y descubrimiento (API de consulta) de servicios Web. Su repositorio central es el registro de negocios, el cual conceptualmente consiste de páginas blancas (información de contacto), páginas amarillas (categorización industrial) y páginas verdes (información técnica de servicios) [OASI04]. SOAP (Simple Object Access Protocol): es un protocolo ligero para el intercambio de información estructurada en un ambiente distribuído y descentralizado. Usa tecnología XML para el intercambio de mensajes entre servicios Web [W3CS07]. Un ejemplo del uso de servicios Web es Amazon y Sabre [SABR09]. Por ejemplo, Amazon consume internamente los servicios Web que ha desarrollado para cumplir con los servicios que ofrece a sus clientes, pero también los ofrece como un servicio a desarrolladores de aplicaciones que deseen usarlos. Algunos de los servicios son por ejemplo: Amazon Flexible Payments Service, Alexa Web Search, Amazon Simple Queue Service (Amazon SQS), etc [AMAZ08]. 2.5 Descripciones WSDL de servicios Web WSDL define una gramática para describir los servicios Web como una colección de puertos de comunicación capaces de intercambiar mensajes. En un documento WSDL la definición abstracta de los puertos y los mensajes está separada de su implementación concreta o enlaces de formato de datos. Esto permite la reutilización de las definiciones abstractas: mensajes, son descripciones abstractas de los datos a ser intercambiados y los tipos de puerto que son colecciones abstractas de operaciones. El protocolo concreto y las especificaciones del formato de datos para un tipo de puerto en particular, constituyen un enlace de reutilización. Un puerto es definido por la asociación de una dirección de red con un enlace de reutilización y una colección de puertos define un servicio [W3CN01]. 22

33 Capítulo 2 Marco teórico Un documento WSDL contiene los siguientes elementos: Types. Message. Operation. Port type. Binding. Port. Service Estructura del documento WSDL Un documento WSDL es simplemente un conjunto de definiciones. El elemento definitions es el elemento raiz, dentro del cual están las definiciones. A continuación se describen los elementos básicos del lenguaje WSDL. Los servicios son definidos usando los siguientes elementos: 1) types: proporciona las definiciones de tipos de datos usados para describir los mensajes intercambiados. 2) message: representa una definición abstracta de los datos a ser transmitidos. Un mensaje consiste de partes lógicas, cada una de las cuales es asociada con una definición en algún tipo de sistema. 3) porttype: conjunto de operaciones abstractas. 4) operation: cada operación se refiere a un mensaje de entrada, un mensaje de salida o un un mensaje de error. 5) binding: especifica el protocolo concreto y el formato de datos para las operaciones y mensajes definidos por un porttype en particular. 6) service: es usado para agregar un conjunto de puertos relacionados. 7) port: especifica una dirección para un binding, así define un único punto final de comunicación. En la figura 2.3 se pueden observar cada uno de los elementos antes descritos, así como la gramática que se usa en el documento WSDL. El uso del elemento import permite la separación de los diferentes elementos en documentos independientes, como ejemplo de esto puede ser poner la definición de los tipos de datos en un XSD independiente del 23

34 Capítulo 2 Marco teórico WSDL. El elemento documentation se puede usar como un contenedor para documentación de lectura. El contenido es arbitrario (texto y elementos mezclados en XSD). Figura 2.3: Estructura del documento WSDL 24

35 Capítulo 2 Marco teórico 2.6 Lenguaje BPEL4WS BPEL4WS o BPEL proporciona una notación y semántica XML para especificar el comportamiento del proceso de negocio basado en servicios Web e introduce mecanismos para el manejo de excepciones del negocio y el procesamiento de fallas. El lenguaje BPEL4WS soporta dos formas diferentes de descripción de los procesos de negocio, procesos abstractos y procesos ejecutables. Los procesos abstractos permiten la especificación del intercambio de mensajes públicos entre las partes (sin incluir los detalles internos de los flujos del proceso). Los procesos ejecutables permiten especificar el detalle exacto de los procesos de negocio y pueden ser ejecutados [BEAS03] Estructura del documento BPEL4WS Como BPEL4WS es un lenguaje basado en XML, el elemento process que es el nodo raiz, representa un proceso que contiene a los demás elementos que permiten la composición. La estructura básica del lenguaje es la siguiente, ver figura ) partnerlinks: se describen las relaciones entre los socios del negocio. 2) partners: un partner es un subconjunto de los partner links que representa las capacidades requeridas de un socio. 3) variables: variables de datos usadas durante el proceso. 4) correlationsets: conjuntos de correlaciones, es un grupo de propiedades que habilitan una conversación. 5) faulthandlers: esta sección contiene los manejadores de fallas, definen las actividades que deben ejecutarse en respuesta a las fallas resultantes de la invocación de los servicios. 6) compensationhandler: esta sección contiene los manejadores de compensación, un manejador de compensación es una envoltura de actividades de compensación. 7) eventhandlers: esta sección contiene los manejadores de eventos, define las actividades a ejecutarse cuando el evento correspondiente ocurre. 8) activity: en esta sección se define el proceso de negocio en el que interactuan los socios. 25

36 Capítulo 2 Marco teórico Figura 2.4: Estructura del documento BPEL4WS. Un proceso BPEL4WS se conforma de varios pasos, cada paso es llamado una actividad. BPEL4WS usa actividades primitivas así como actividades de estructura. Las actividades primitivas representan construcciones básicas y son usadas para tareas comunes: <assign> <compensate> <empty> <invoke> <receive> <reply> <throw> <wait> Para definir algoritmos complejos que especifiquen exactamente los pasos de los procesos de negocio, se usan las actividades de estructura, tales como: <flow> <pick> 26

37 Capítulo 2 Marco teórico <sequence> <scope> <switch> <while> En este capítulo se ha presentado el marco teórico el cual sirve de referencia para entender la base de esta investigación. Cada uno de los temas expuestos anteriormente serán aplicados en la metodología a desarrollar, tomándo en cuenta que de cada tema se seleccionarán aquellas características que aporten una solución para conseguir el objetivo de esta tesis. 27

38 Capítulo 3 Lenguajes de transformación Para realizar una transformación de modelos es necesario establecer un lenguaje que permita el mapeo entre ellos. Sin embargo, cada uno de los lenguajes tiene características que los hacen más eficientes o no con determinados modelos. Por tal motivo, la elección del lenguaje de transformación debe ser acorde al tipo de transformación que se requiera y con ayuda de éste obtener el modelo destino o el resultado deseado. A continuación, se presenta una breve descripción de los lenguajes analizados: ATL, QVT, MOFScript y XSLT. La decisión de analizar estos lenguajes se debe a que algunos de ellos se basan en especificaciones aceptadas por la OMG o en el caso de XSLT porque la transformación es sobre documentos XML. Al final se concluye cuál lenguaje será el seleccionado para realizar la transformación del modelo orientado a servicios a sus correspondientes descripciones de WSDL y BPEL. Los lenguajes QVT (Query View Transformation) y ATL están basados en un lenguaje descriptivo OCL (Object Constraint Language). Estos lenguajes usan la semántica de OCL para describir asignaciones u otras especificaciones en sus reglas de transformación. 28

39 Capítulo 3 Lenguajes de transformación 3.1 OCL (Object Constraint Language) Es un lenguaje formal usado para describir expresiones en modelos UML. Estas expresiones especifican condiciones invariantes que deben mantenerse en el sistema que es modelado. Las expresiones OCL pueden ser usadas para especificar operaciones/acciones que no alteran el estado del sistema cuando se ejecutan. OCL es un lenguaje de especificación pura, por lo tanto, cuando una expresión OCL es evaluada, simplemente regresa un valor pero no puede cambiar nada en el modelo. No es un lenguaje de programación, no es posible escribir lógica de programa o control de flujo, y tampoco se pueden invocar procesos, ya que es un lenguaje de modelado. Cada expresión OCL está escrita en el contexto de una instancia de un tipo específico (un tipo se refiere a un clasificador, como una clase). En una expresión OCL, la palabra reservada self es usada para referirse a la instancia contextual. Por ejemplo, si el contexto es Compañia, entonces self se refiere a una instancia de tipo Compañia. Un ejemplo de expresión OCL puede ser: context Compañia inv: self.numerodeempleados > 50 En este caso, es una expresión invariante, ya que se especifica que el número de empleados siempre debe exceder 50 para las instancias de tipo Compañía. El lenguaje de restricciones OCL, sólo permite especificar y detallar modelos, pero no realiza ningún tipo de transformación. 3.2 Lenguajes de transformación ATL (ATLAS Transformation Language) ATL es un lenguaje de transformación de modelos que permite especificar como uno o más modelos objetivo pueden ser producidos desde un conjunto de modelos fuente. Es un lenguaje especificado como un metamodelo y que cuenta con una sintaxis concreta de texto. ATL es la respuesta a la propuesta por petición (RFP por sus siglas en inglés) de la OMG MOF QVT RFP [ATLA06], para la transformación de modelo a modelo. Las operaciones de transformación pueden ser especificadas por medio de módulos ATL. El lenguaje también permite desarrollar librerías ATL independientes para ser importadas El lenguaje ATL es un híbrido entre programación declarativa e imperativa. El estilo preferido de transformación escrita es la declarativa, ya que permite expresar simplemente mapeos entre los elementos del modelo fuente y destino. Un programa de transformación 29

40 Capítulo 3 Lenguajes de transformación ATL está compuesto de reglas que definen como los elementos del modelo fuente son mapeados para crear los elementos del modelo destino. Ejemplo de regla ATL: rule Author { from a : MMAuthor!Author to p : MMPerson!Person ( name <- a.name, surname <- a.surname) } En la regla Author se hace una transformación de los elementos del modelo fuente a a los elementos del modelo objetivo p. El lenguaje ATL es el lenguaje oficial del proyecto Eclipse M2M. ATL se enfoca principalmente a la transformación de modelo a modelo, y está basado en OCL. Aplicando la serie de reglas al modelo fuente se obtiene el modelo resultante en un archivo XMI QVT (Query View Transformation) QVT es una especificación que tiene una naturaleza híbrida declarativa/imperativa, siendo la parte declarativa dividida en una arquitectura de dos niveles. Esta arquitectura forma el framework para la ejecución semántica de la parte imperativa. La parte declarativa está formada por: el lenguaje de relaciones (Relations) y el lenguaje núcleo (Core). En el lenguaje Relations una transformación entre modelos es especificada como un conjunto de relaciones que deben poseer los modelos para que la transformación sea exitosa. Las relaciones en una transformación declaran restricciones que deben ser satisfechas por cada uno de los elementos de los modelos. Una relación, definida por uno o más dominios y un par de predicados when y where, especifican un enlace que deben tener los elementos de los modelos. Un ejemplo del tipo de regla de transformación es la siguiente: relation PackageToSchema /* map each package to a schema */ { domain uml p:package {name=pn} domain rdbms s:schema {name=pn} } La palabra reservada domain es una variable asociada a un tipo de modelo. En el ejemplo se observa que dos dominios son declarados y emparejarán los elementos en los modelos uml y rdbms. 30

41 Capítulo 3 Lenguajes de transformación En el lenguaje Core una transformación es especificada como un conjunto de mapeos que declara restricciones que deben existir entre los elementos del modelo de un conjunto de modelos. La sintaxis para realizar una transformación del lenguaje Core de QVT es complicada y no es comunmente usada. La especificación QVT soporta un tercer lenguaje llamado Operational Mappings. Este lenguaje imperativo es similar a un lenguaje de programación procedural. Al igual que los otros lenguajes declarativos de QVT este también está basado en OCL y produce el modelo destino en XMI. Una transformación operacional representa una transformación unidireccional. El punto de entrada de cualquier transformación es llamada main, a continuación se muestra un ejemplo. transformation Uml2Rdbms(in uml:uml,out rdbms:rdbms) { // the entry point for the execution of the transformation main() { uml.objectsoftype(package)->map packagetoschema(); }. } Este lenguaje permite crear módulos a través de reglas de mapeo, usando la palabra mapping MOFScript El lenguaje MOFScript está diseñado bajo algunos conceptos tomados de QVT pero haciendo uso de un conjunto limitado. Muchos conceptos de QVT no son esenciales para las transformaciones modelo a texto. Por otro lado, hay requerimientos adicionales en las transformaciones modelo a texto que no son cubiertas por QVT, como lo es la generación de un archivo de salida. MOFScript es un lenguaje de transformación y también es una herramienta que puede generar texto a partir de modelos basados en MOF. Puede tener como entrada varios modelos y el archivo que se genera puede ser de cualquier tipo (Java, C#, HTML, XML, etc). Aspectos como: generación de texto, mecanismos de control, manipulación de cadenas, producción de archivos de salida, entre otros; son características que cubre esta herramienta. La herramienta MOFScript está desarrollada como un plug-in de Eclipse, usa metamodelos y modelos basados en MOF como entrada para las transformaciones. El plug-in MOFScript de Eclipse es desarrollado para proporcionar una herramienta de generación de código amigable al usuario para metamodelos arbitrarios. El lenguaje ha sido presentado al proceso de la OMG para la transformación de modelo a texto. La 31

42 Capítulo 3 Lenguajes de transformación herramienta MOFScript es parte del conjunto de herramientas Eclipse GMT, una colección de herramientas de soporte a la ingeniería dirigida por modelos basada en Eclipse. La sintaxis está bien definida y permite modularizar la transformación a través de reglas de mapeo. Un ejemplo de regla de transformación se muestra enseguida. texttransformation MultipleMetaModels (in uml:" in ec:" { main () { // can also use module::main, which is the same uml.objectsoftype (uml.class)->foreach (cl) { cl.ecoremodeltest() } // '\n Looking for ecore objects' ec.objectsoftype (ec.eclass)->foreach (eccl) { eccl.umlmodeltest() } } En la regla mostrada arriba se indica que son dos modelos de entrada, un modelo uml y otro modelo ec. La palabra reservada main representa la regla principal, la cual es la primera en ser ejecutada. La primera línea de ejecución indica que se debe realizar un ciclo por todos los objetos de tipo Class que se encuentren contenidos en el modelo uml. Cada objeto de tipo Class es asignado a una variable cl, la variable cl tiene declarada una regla ecoremodeltest, la cual debe ser ejecutada XSLT (Transformation XSL) XSLT es un lenguaje para transformar documentos XML en otros documentos XML. XSLT está diseñado para usarse como parte de XSL, el cual es un lenguaje de hoja de estilo para XML. XSL especifica el estilo de un documento XML mediante el uso de XSLT para describir como el documento es transformado en otro documento XML. Una transformación expresada en XSLT describe reglas para transformar un árbol fuente en un árbol resultante. La transformación es producida mediante una asociación de patrones con plantillas. Un patrón es mapeado contra los elementos del árbol fuente. Una transformación expresada en XSLT es llamada una hoja de estilo. Ya que cuando XSLT es transformado al vocabulario de formato XSL, la transformación funciona como una hoja de estilos. Una hoja de estilos contiene un conjunto de reglas de plantilla. Una regla de plantilla tiene dos partes: un patrón el cual es emparejado contra los nodos en el árbol fuente y una plantilla la cual puede ser instanciada para formar parte del árbol resultante. 32

43 Capítulo 3 Lenguajes de transformación 3.3 Lenguaje a usar en este proyecto El lenguaje OCL sirve para agregar restricciones a modelos UML y para hacer que el modelo de la aplicación sea más específico. Por lo que no es adecuado para usar en esta tesis, ya que los modelos que se usan ya son lo suficientemente detallados y no se necesita más especificación. Otra de las razones es que no es propiamente un lenguaje de transformación. Sin embargo lenguajes como ATL y QVT están basados en algunos conceptos de OCL. Los lenguajes ATL y QVT están enfocados a realizar transformaciones de modelo a modelo. Para este trabajo, no se pretende realizar un modelo de los documentos WSDL y BPEL. Y por lo tanto estos dos lenguajes no son los indicados para ser usados en la transformación. El lenguaje XSLT realiza transformaciones de documentos XML a XML. Esto no es lo que se busca, debido a que nuestro objetivo no es transformar archivos XML y darles formato. En base a los lenguajes descritos, se ha concluido que el lenguaje adecuado para aplicar en esta tesis es MOFScript. Ya que este lenguaje y herramienta se ajusta a las características deseadas del producto resultante de la tesis (descripciones de los servicios Web en WSDL y la composición en BPEL). MOFScript como lenguaje proporciona la sintaxis para crear las reglas de transformación y como herramienta permite convertir un modelo basado en un metamodelo MOF en un archivo de texto Lenguaje MOFScript A continuación se describen las construcciones del lenguaje MOFScript Transformación de texto Un Texttransformation define el nombre del módulo. El nombre puede ser cualquiera y es independendiente del nombre de archivo. Para definirlo se puede usar indistintamente texttransformation o textmodule. Define el metamodelo de entrada en términos de un parámetro. texttransformation transformacionuml (in uml:" Puede tener varios modelos como entrada y estos deben de separarse por comas Reglas del punto de entrada Las reglas del punto de entrada definen donde empieza la ejecución de la transformación. Puede tener un contexto (en el ejemplo uml.model), el cual define que tipo de elemento del 33

44 Capítulo 3 Lenguajes de transformación metamodelo será el punto de inicio para la ejecución. El cuerpo de la regla contiene declaraciones. uml.model::main () { self.ownedmember->foreach(p:uml.package) { p.mappackage() } } Un punto de entrada puede tener un tipo de contexto con varias instancias. En ese caso el punto de entrada será ejecutado para cada instancia del tipo. uml.class::main () { class: self.name } Tanto las reglas generales como las reglas del punto de entrada puede ser especificadas sin tipo de contexto. Un punto de entrada de este tipo será ejecutada una vez. La declaración se hace usando la palabra module o sin ninguna palabra. Para recuperar el modelo de entrada usando este enfoque, el parámetro del modelo para la transformación debe ser usado (en este caso uml), combinado con la operación objectsoftype para recuperar los objetos contenidos en el modelo. module::main () { uml.objectsoftype (uml.package) } main () { uml.objectsoftype (uml.package) } Reglas Las reglas son como funciones. Pueden tener un tipo de contexto, el cual es un tipo de metamodelo. También pueden retornar un valor. El cuerpo de una regla contiene un conjunto de declaraciones. uml.package::mappackage () { self.ownedmember->foreach(c:uml.class) c.mapclass() } uml.class::mapclass(){ file (package_dir + self.name + ext) self.classpackage() self.standardclassimport () self.standardclassheadercomment () public class self.name extends Serializable { 34

45 Capítulo 3 Lenguajes de transformación 35 self.classconstructor() /* * Attributes */ self.ownedattribute->foreach(p : uml.property) { p.classprivateattribute() } newline(2) } } Una regla puede regresar un valor, el cual puede ser reutilizado en expresiones en otras reglas. La declaración result es usada para regresar un valor. uml.package::getfullname (): String { if (self.owner!= null) result = self.owner.getfullname() + "." else if (self.ownerpackage!= null) result = self.ownerpackage.getfullname() + "." result += self.name.tolower().replace(" ", "_"); } Una regla puede tener parámetros. uml.model::testparameters2 (s1:string, i1:integer) { stdout.println("testparameters2: " + s1 + ", " + i1)} uml.model::testparameters3 (s1:string, r2:real, b1:boolean, package:uml.package) { stdout.println("package:" + package.name) stdout.println ("testparameters3: " + s1 + ", " + r2 + ", " + b1 + " " + package.name)} Propiedades y variables Una propiedad es una constante, una variable puede cambiar su valor durante el tiempo de ejecución. property nombrepaquete:string = org.mypackage var mientero= Archivos La palabra clave file permite la generación de un archivo de salida. Se puede especificar la ruta de la salida. file (c.name +.java ) file ( c:\tmp\ + c.name +.java ) file f2 ( test.java ) f2.println ( \t\t output to file f2 )

46 Capítulo 3 Lenguajes de transformación Declaración de impresión Las declaraciones de impresión proporcionan salida a un dispositivo de salida, el cual puede ser un archivo o la salida en pantalla. println ( public class + c.name) Otras opciones MOFScript permite hacer uso de iteradores (while, foreach), condicionales (if, else if). El iterador foreach puede iterar cadenas, enteros, listas. Además se pueden invocar métodos externos de java. Se pueden manipular cadenas, realizar operaciones con enteros e igualmente con listas. Además, cuenta con operaciones de utilidad y del sistema Herramienta MOFScript La herramienta MOFScript es una implementación del lenguaje de transformación de modelo a texto MOFScript. Soporta el análisis sintáctico, verificación y ejecución de scripts MOFScript. Fue desarrollado por Sintef ICT en el proyecto MODELWARE soportado por la Unión Europea [OLDE06b]. MOFScript es implementado como un conjunto de plug-ins de Eclipse, los cuales necesitan ser instalados para funcionar dentro de este ambiente. La versión de Eclipse en la que se ha probado que funciona MOFScript y que se está usando es Eclipse Los plugins usados son: ANTLR 4.1.1, EMF 2.3.2, UML y por último MOFScript Los archivos que usa la herramienta MOFScript para guardar y ejecutar las reglas de transformación tienen la extensión *.m2t. 36

47 Capítulo 4 Definición del metamodelo para la transformación En el capítulo 3 se explica que para llevar a cabo una transformación se debe usar un lenguaje de transformación. El lenguaje que se seleccionó fue MOFScript, este lenguaje tiene algunas restricciones para poder usarse, una restricción es que para realizar las transformaciones se deben usar modelos basados en MOF [OLDE06b]. MOF es un meta-metamodelo que permite definir metamodelos, los cuales pueden ser específicos de dominio o de propósito general como lo es UML. MOF se encuentra en el nivel M3 dentro de la arquitectura de cuatro niveles que define la OMG [MOF02]. La arquitectura de cuatro niveles permite ubicar el nivel de abstracción de un metamodelo. El metamodelo orientado a servicios [ESTR08], usado para este trabajo de tesis, puede ser ubicado en el nivel M2. Sin embargo, el metamodelo no está basado en MOF pero es un modelo de dominio específico. Más adelante se explican los niveles mencionados anteriormente. 37

48 Capítulo 4 Definición del metamodelo para la transformación Para el fin que se persigue en esta tesis, se requiere de un metamodelo que permita ser manejado por las herramientas existentes que soporten modelos MOF. Por lo tanto, se ha hecho el análisis de las características de dos metamodelos que tienen soporte en varias herramientas de transformación: UML y modelos EMF (Ecore). 4.1 MOF El metamodelo MOF es uno de los estándares principales de MDA para compartir metadatos. MOF es usado para definir diferentes tipos de lenguajes de modelado. Además, es usado como una herramienta para diseñar e implementar sistemas de modelado más sofisticados. MOF proporciona un pequeño conjunto de conceptos de modelado y en base a estos conceptos se pueden crear nuevos lenguajes, tales como: Clases: modela metaobjetos MOF. Asociaciones: modela relaciones binarias entre metaobjetos. Tipos de datos: modela otros datos (tipos primitivos, tipos externos, etc). Paquetes: modulariza los modelos. El modelo MOF es orientado a objetos y es autodescrito, es formalmente definido usando sus propios constructores de metamodelado. Además, es suficientemente expresivo, que soporta modificaciones y extensiones. 4.2 Arquitectura de cuatro niveles La estructura clásica para el metamodelado está basada en una arquitectura con cuatro metacapas. Esta arquitectura es definida por la OMG (ver figura 4.1), y las capas son descritas como sigue [FUEN04]: 38 Figura 4.1: Arquitectura de cuatro niveles [MOF02]

49 Capítulo 4 Definición del metamodelo para la transformación Nivel M0 - instancias: modela el sistema real y sus elementos son las instancias que componen dicho sistema. Ejemplos son los elementos el cliente Alberto que ha comprado el ejemplar 200 del libro Delirio. Nivel M1 modelo del sistema: los elementos del nivel M1 son los modelos de los sistemas concretos. En el nivel M1 es donde se definen, los conceptos de Cliente, Compra y Libro (cada uno con sus atributos nombre, num. ejemplar, titulo, etc). Existe una relación muy estrecha entre los elementos del nivel M0 y M1: los conceptos del nivel M1 definen las clasificaciones de los elementos del nivel M0, mientras que los elementos del nivel M0 son las instancias de los elementos del nivel M1. Nivel M2- el modelo del modelo (metamodelo): los elementos del nivel M2 son los lenguajes de modelado. El nivel M2 define los elementos que intervienen a la hora de definir un modelo del nivel M2, los elementos son: Clase, Atributo o Asociación. Existe una gran relación entre los conceptos de los niveles M1 y M2: los elementos del nivel superior definen las clases de elementos válidos en un determinado modelo de nivel M1, mientras que los elementos del nivel M1 pueden ser considerados como instacias de los elementos del nivel M2. Nivel M3- el modelo de M2 (el meta-metamodelo): finalmente, el nivel M3 define los elementos que constituyen los distintos lenguajes de modelado. De esta forma, el concepto clase definido en UML (que pertenece al nivel M2) puede verse como una instancia del correspondiente elemento del nivel M3, en donde se define de forma precisa ese concepto, así como sus características y las relaciones con otros elementos (ejemplo: una clase es un clasificador, y puede tener asociado un comportamiento y además dispone de un conjunto de atributos y operaciones). 4.3 Metamodelos Dentro de la arquitectura de cuatro niveles el metamodelo del modelo orientado a servicios [ESTR08] puede ser ubicado en el nivel M2. Este metamodelo no está basado en MOF y para ser usado con las herramientas de transformación aceptadas por la OMG, es necesario que los modelos estén basados en MOF. Por lo tanto, se necesita de un metamodelo intermedio y dentro de los metamodelos soportados por las herramientas existentes se encuentran UML y EMF Ecore. Para crear el metamodelo intermedio que se necesita para esta tesis, se puede modelar usando un perfil UML o crear el metamodelo de los elementos necesarios del metamodelo de dominio específico con Ecore. A continuación se presenta una descripción de estas dos opciones de modelado. 39

50 Capítulo 4 Definición del metamodelo para la transformación Perfil UML UML es un lenguaje que actualmente es el estándar para modelar cualquier tipo de sistema, además de tener soporte por muchas herramientas de programación. Es un lenguaje de propósito general y flexible que permite extensiones. UML incluye mecanismos de extensión que permiten definir lenguajes de modelado que son derivados de UML. Los mecanismos de extensión permiten adaptar y extender UML al agregar nuevos bloques de construcción, creando nuevas propiedades y especificando nueva semántica para hacer el lenguaje apropiado para el dominio del problema específico. Hay tres mecanismos de extensión comunes: estereotipos, valores etiquetados y restricciones. Estos mecanismos se denominan Perfiles UML. Algunas de las razones por las que se decide crear un Perfil UML para adaptar un metamodelo existente son: Disponer de una terminología y vocabulario propio de un dominio de aplicación. Definir una sintaxis para construcciones que no cuentan con una notación propia. Definir una nueva notación para símbolos ya existentes, más acorde con el dominio de la aplicación objetivo. Añadir cierta semántica que no existe en el metamodelo. Añadir restricciones a las existentes en el metamodelo, restringiendo su forma de utilización. Añadir información que puede ser útil a la hora de transformar el modelo de otros modelos, o a código. Un Perfil UML se define en un paquete UML, estereotipado <<profile>>, que extiende a un metamodelo o a otro Perfil UML Metamodelo basado en EMF Ecore Eclipse Modeling Framework (EMF) es un framework de modelado para Eclipse. Un modelo en EMF, a diferencia de un modelo definido con UML, es menos general y no requiere una metodología completamente diferente o alguna herramienta sofisticada de modelado. El metamodelo núcleo en EMF es llamado Ecore, es usado para representar modelos en EMF. Ecore es en sí un modelo EMF y por lo tanto es su propio metamodelo. 40

51 Capítulo 4 Definición del metamodelo para la transformación Hay cuatro clases Ecore que se usan para representar modelos [BUDI03]: EClass: es usado para representar una clase modelada. Tiene un nombre, cero o más atributos y cero o más referencias. EAttribute: es usado para representar un atributo modelado. Los atributos tienen un nombre y un tipo. EReference: es usado para representar el fin de una asociación entre clases. Tiene un nombre, una bandera boleana para indicar si representa contención y un tipo de objetivo de referencia, el cual es otra clase. EDataType: es usado para representar el tipo de un atributo. Un tipo de dato puede ser un tipo primitivo, como int o float o un tipo de objeto. Los nombres de las clases corresponden estrechamente a los términos de UML, esto es porque Ecore es un pequeño subconjunto simplificado de UML [BUDI03]. El modelo EMF permite especificar los datos de la aplicación representándolos en un diagrama de clases. A partir de una especificación del modelo, EMF puede generar código de implementación eficiente, correcto y fácilmente adaptable. EMF proporciona soporte para Java, UML y XML, además de contar con soporte de varias herramientas dentro del framework Eclipse. EMF está relacionado con UML en un solo aspecto, el modelado de clases. Además, evita algunas complejidades por lo que resulta en una implementación optimizada ampliamente aplicable. 4.4 Selección del metamodelo EMF Ecore Después de haber analizado los metamodelos UML y Ecore, se ha seleccionado a Ecore como el metamodelo adecuado para realizar el metamodelo del modelo de dominio específico del trabajo [ESTR08]. Las características que se necesitan del metamodelo para este trabajo de tesis son: conjunto reducido de elementos de modelado, facilidad para ser extendido, aceptación por las herramientas de transformación y que pueda ser representado en XML. Ecore es un metamodelo que cuenta con estas propiedades, ya que es un metamodelo con elementos que son un subconjunto de UML, está basado en MOF, tiene soporte con varias herramientas dentro del framework Eclipse y es serializable (representación en bytes que pueda recuperarse después como XML). Ecore permite representar metamodelos de un dominio específico usando sólo aquellos elementos que sean necesarios modelar. Por el contrario, el crear un Perfil UML involucra un trabajo más complicado porque es un lenguaje con muchos elementos de modelado y para este trabajo de tesis no es necesario modelar por completo el metamodelo de dominio específico. 41

52 Capítulo 4 Definición del metamodelo para la transformación 4.5 Metamodelo intermedio MOS El modelo organizacional orientado a servicios lo hemos llamado MOS para ser referido en este trabajo. El modelo MOS cuenta con diferentes transformaciones PIM con el fin de alcanzar un nivel muy detallado. Va desde un nivel de abstracción usado por el usuario hasta un nivel concreto de operaciones, pero el modelo no está basado en MOF. Por tal motivo debe crearse el metamodelo intermedio basado en MOF que sirva de enlace entre los elementos del modelo organizacional orientado a servicios y los elementos de las especificaciones WSDL y BPEL. A continuación se presenta el metamodelo para representar el metamodelo intermedio MOS y las razones por las cuales fue seleccionado. También se presentan los elementos MOS y los atributos que serán considerados en la transformación a elementos WSDL y BPEL. Al final se muestra el metamodelo que se convierte a Ecore usando UML2 tool kit Características del metamodelo El modelo organizacional orientado a servicios MOS es un modelo de dominio específico. Este modelo permite expresar la manera en que el usuario concibe los servicios que son ofrecidos por una empresa. Para transformar este modelo orientado a servicios a una especificación WSDL de cada servicio, se necesita crear un metamodelo intermedio. Este metamodelo es necesario debido a algunas razones, como son: el nivel de abstracción del modelo de dominio específico está fuera de los estándares y especificaciones actuales de la OMG; los lenguajes y las herramientas de transformación existentes sólo soportan metamodelos basados en MOF. El metamodelo intermedio debe cumplir con algunas características. Éstas deben de cubrir aspectos para lograr la transformación, aspectos como los siguientes: Toda transformación MDA debe ser realizada con metamodelos MOF, debido a que es un estándar de la OMG. Flexibilidad para representar elementos de los modelos de dominio específico. Que sea soportado por las herramientas de transformación existentes. Por lo tanto, las características del metamodelo intermedio deben ser: Estar basado en el meta metamodelo MOF. Que pueda ser extendido para tener una correspondencia clara con el metamodelo orientado a servicios. 42

53 Capítulo 4 Definición del metamodelo para la transformación Que permita realizar un mapeo de elementos de forma más natural hacia las especificaciones WSDL. Que tenga soporte para ser usado, para este trabajo, con la herramienta de transformación MOFScript. El metamodelo que cumple con las características es Ecore, debido a que está basado en MOF y es flexible para representar metamodelos de dominio específico. El lenguaje y herramienta que será usado para realizar la transformación es MOFScript. Esta herramienta sólo admite modelos basados en MOF y permite producir archivos de salida; y como lenguaje se basa en una sintaxis bien definida para declarar las reglas de transformación de una manera sencilla. Es importante aclarar que el metamodelo Ecore, será usado de forma interna para la transformación. Es decir, no se usará para modelar con él, sino que el metamodelo que se produce como resultado de esta investigación será usado por su estructura XML y será almacenado en el repositorio de metamodelos en el editor de MOFScript. El metamodelo resultante se llama mos.ecore y servirá por su estructura XML, ya que representará el metamodelo que permitirá crear modelos MOS. El metamodelo mos.ecore permitirá crear modelos nombre.mos y serán estos modelos *.mos los que serán transformados a las especificaciones WSDL y BPEL Selección de elementos del metamodelo MOS a ser mapeados a elementos WSDL y BPEL4WS Para crear el metamodelo Ecore del metamodelo orientado a servicios, deben considerarse aquellos elementos de MOS que sean los indicados para ser representados en las especificaciones WSDL y BPEL. Además de considerar los atributos necesarios que permitan establecer esa relación de mapeo entre los diferentes elementos. A continuación en la tabla 4.1 se muestran los elementos MOS que serán representados en elementos WSDL y BPEL. Estos elementos son tomados de los modelos propuestos en el trabajo [ESTR08], los modelos corresponden a diferentes etapas de refinamiento en el proceso de modelado, por lo tanto los elementos de cada modelo se desglosan en otros elementos hasta llegar a la unidad que son los recursos. En la tabla los modelos son mencionados de acuerdo al nivel de abstracción de representación. Tabla 4.1: Selección de elementos MOS Modelos MOS Modelo global, modelado de servicios compuestos Modelo de procesos Modelo de protocolo Elementos MOS Servicio compuesto Servicio básico Proceso Tarea Recurso 43

54 Capítulo 4 Definición del metamodelo para la transformación El elemento servicio compuesto es el que engloba a los otros elementos. Sin embargo, de acuerdo al análisis que a continuación se presenta el elemento proceso es el que representa al servicio de la especificación WSDL. El elemento proceso contiene tareas, las cuales son las unidades mínimas de acción y en consecuencia son las que representan las operaciones de los servicios. Por último, el elemento recurso representa el o los parámetros de las operaciones. A continuación se describen los atributos que deben ser considerados para el mapeo de los elementos Descripción de los atributos de los elementos MOS Algunos de los atributos que deben ser considerados para el mapeo, no están especificados en los modelos de negocio orientados a servicios. Estos atributos deben ser agregados a los elementos MOS para realizar una transformación directa a los elementos de los documentos WSDL y BPEL. La identificación de algunos atributos no estaba considerada al principio de la investigación, durante el desarrollo de ésta se ha acordado puntualizar cuáles son los atributos que ya se consideraban en el trabajo [ESTR08] y cuáles son los atributos agregados. Los atributos son necesarios para una correcta aplicación de las reglas de transformación, de esta forma los elementos MOS con los atributos correspondientes tendrán un mapeo directo a los elementos WSDL o BPEL dependiendo de la transformación aplicada. A continuación se describen los atributos de cada elemento, se indica si ya están considerados o si es un atributo nuevo Atributos del servicio compuesto El servicio compuesto ya cuenta con el atributo Nombre, los atributos que se están considerando agregar son Orden de ejecución y Descripción. La justificación de estos atributos, es que el atributo Orden de ejecución será considerado para los servicios compuestos que estén contenidos en un servicio compuesto superior. El atributo se necesita para realizar la composición en BPEL, para saber el orden de participación. Mientras que el atributo Descripción permitirá agregar la descripción detallada de la acción que realiza el servicio Atributos del servicio básico El servicio básico ya cuenta con el atributo Nombre, los atributos que se están considerando agregar son Orden de ejecución y Descripción. La justificación de estos atributo, es que Orden de ejecución será usado para la composición de servicios en BPEL, para saber el orden de participación. El atributo Descripción permitirá agregar la descripción detallada de la acción que realiza el servicio. 44

55 Capítulo 4 Definición del metamodelo para la transformación Atributos del proceso El proceso ya cuenta con los atributos Nombre, Transaccional y Orden de ejecución. El atributo Orden de ejecución ya está considerado gráficamente dentro del modelado, pero debe ser especificado dentro del proceso. El atributo Orden de ejecución será usado para la composición de servicios en BPEL, para saber el orden de participación. Es importante hacer notar que el proceso será considerado como la representación de un servicio Web, el cuál a su vez formará parte del servicio básico. El otro atributo que debe agregarse es Descripción, ya que éste permitirá agregar la descripción detallada de la actividad que realiza el proceso Atributos de la tarea La tarea ya cuenta con el atributo Nombre. Los atributos que se están considerando agregar son Transaccional, Orden de ejecución, Tipo y Descripción. El atributo Transaccional indica si la tarea será representada en el documento WSDL como operación. El atributo Orden de ejecución será usado para la composición de servicios en BPEL, para saber el orden de participación. Por último, el atributo Tipo indica el tipo de recurso que genera (si es el caso), y será usado para representar el esquema xsd de tipos en el documento WSDL. El atributo Descripción permitirá agregar la descripción de la actividad que realiza la tarea, así como describir cómo usa los elementos que recibe o genera Atributos del recurso El recurso ya cuenta con el atributo Nombre, los atributos que se está considerando agregar son Tipo y Descripción. El atributo Tipo indica el tipo de recurso que será usado para representar el esquema xsd de tipos en el documento WSDL. El atributo Descripción permitirá agregar la descripción del atributo. El atributo Descripción no es estrictamente obligatorio, al contrario de los otros que si lo son. Es recomendable hacer uso de éste, para aclarar la actividad de cada elemento, así como para ser agregado como documentación en la especificación WSDL Restricciones de los atributos de los elementos MOS Cada atributo debe tener restricciones asociadas, que determinan los valores que pueden ser asignados. De cada uno de los elementos se listarán sus atributos y los valores que pueden recibir éstos Restricciones de los atributos del servicio compuesto Nombre: atributo de tipo cadena, aquí se almacena el nombre del servicio compuesto. Orden de ejecución: atributo de tipo entero, aquí se almacena el número de orden de participación en el proceso de negocio. En caso de ser un servicio compuesto 45

56 Capítulo 4 Definición del metamodelo para la transformación dentro de otro servicio compuesto, el atributo Orden de ejecución debe tener asignado un valor mayor a 0 y será incrementado consecutivamente. De ser un servicio compuesto que ya no está contenido dentro de otro, debe tener asignado 0. Descripción: atributo de tipo cadena Restricciones de los atributos del servicio básico Nombre: atributo de tipo cadena, aquí se almacena el nombre del servicio básico. Orden de ejecución: atributo de tipo entero, aquí se almacena el número de orden de participación en el proceso de negocio. En caso de ser un servicio básico dentro de un servicio compuesto, el atributo Orden de ejecución debe tener asignado un valor mayor a 0 y será incrementado consecutivamente. De ser un servicio básico que no esté contenido dentro de un servicio compuesto, debe tener asignado 0. Descripción: atributo de tipo cadena Restricciones de los atributos del proceso Nombre: atributo de tipo cadena, aquí se almacena el nombre del proceso. Transaccional: atributo de tipo cadena, los valores asignados pueden ser T transaccional o NT no transaccional. Si el valor es T, el proceso será considerado para ser transformado a elementos WSDL. Si el valor es NT, significa que es una operación manual. Orden de ejecución: atributo de tipo entero, aquí se almacena el número de orden de participación en el proceso de negocio. El atributo Orden de ejecución debe tener asignado un valor mayor a 0 y será incrementado consecutivamente. Descripción: atributo de tipo cadena Restricciones de los atributos de la tarea Nombre: atributo de tipo cadena, aquí se almacena el nombre de la tarea. Transaccional: atributo de tipo cadena, los valores asignados pueden ser T transaccional o NT no transaccional. Si el valor es T, la tarea será considerada para ser transformada a elementos WSDL. Si el valor es NT, significa que es una operación manual. Orden de ejecución: atributo de tipo entero, aquí se almacena el número de orden de participación en el proceso de negocio. El atributo Orden de ejecución debe tener asignado un valor mayor a 0 y será incrementado consecutivamente. Tipo: atributo de tipo cadena, los valores asignados pueden ser: void, int, boolean, string y float. La tarea puede generar recursos, es por ello que debe de ser tipeada. En el caso de que no genere ningún recurso debe ser tipeada con void. Descripción: atributo de tipo cadena. 46

57 Capítulo 4 Definición del metamodelo para la transformación Restricciones de los atributos del recurso Nombre: atributo de tipo cadena, aquí se almacena el nombre del recurso. Tipo: atributo de tipo cadena, los valores asignados pueden ser: int, boolean, string y float. Descripción: atributo de tipo cadena. En la tabla 4.2 se presenta un resumen de los elementos que serán mapeados a elementos Ecore, junto con los atributos que deben ser considerados para poder realizar una transformación a elementos de la especificación WSDL. Tabla 4.2: Elementos MOS a considerar para representarlos en el metamodelo Ecore Modelos MOS Elementos MOS Atributos a considerar para la transformación a WSDL Modelo global, modelado de servicios compuestos Servicio compuesto Nombre Orden de ejecución Descripción Servicio básico Nombre Orden de ejecución Descripción Modelo de procesos Proceso Nombre Transaccional Orden de ejecución Descripción Modelo de protocolo Tarea Nombre Transaccional Orden de ejecución Tipo Descripción Recurso Nombre Tipo Descripción Representación gráfica de los atributos en los elementos MOS Para poder representar los atributos en los elementos MOS, deben hacerse algunas modificaciones gráficas a las ya establecidas en [ESTR08]. En la tabla 4.3 se muestran los elementos gráficos y los atributos que han sido considerados para agregar gráficamente. A los servicios (compuesto y básico) se les agrega el atributo orden de ejecución, el cuál está representado gráficamente como No. en la tabla, pero debe escribirse un número entero en su lugar. El atributo proceso igualmente se le debe agregar el atributo orden de ejecución como No. y para el atributo transaccional debe escribirse T o NT. El elemento 47

58 Capítulo 4 Definición del metamodelo para la transformación tarea debe modificarse para agregar los atributos transaccional y orden de ejecución de forma gráfica, la representación será igual que en los casos anteriores. Finalmente en el elemento recurso debe agregarse gráficamente el atributo Tipo. Tabla 4.3: Elementos gráficos MOS Nombre del elemento Servicio compuesto Servicio básico Proceso Elemento gráfico y atributos Tarea Recurso Al realizar el análisis del prototipo que permitirá crear los modelos *.mos, se considerará la forma más pertinente de representar los elementos MOS y sus atributos. La representación gráfica mostrada anteriormente en la tabla 4.3, es sólo para familiarizarse con el trabajo [ESTR08], en donde los elementos son representados con esas figuras. El atributo Descripcion estaría representado de forma oculta, es decir no es un atributo que deba sobresalir sobre el elemento gráfico, ya que este atributo es considerado como apoyo de documentación. Igualmente el atributo Tipo del elemento tarea estará oculto Representación de los elementos MOS con UML2 Para realizar el metamodelo Ecore, primero se deben modelar los elementos a mapear usando UML2 de Eclipse, a través de la distribución de Eclipse Modeling Tools. La figura 4.2 muestra la representación del metamodelo MOS en UML2. La versión usada es Eclipse SDK, version: 3.4.2, Build id: M El plug-in de UML2 es la versión v

59 Capítulo 4 Definición del metamodelo para la transformación Figura 4.2: Metamodelo MOS usando UML Generación del metamodelo MOS Ecore a partir de UML2 El siguiente paso a realizar es convertir el metamodelo representado en UML2 a Ecore. En la barra de herramientas está el menu de UML Editor, se selecciona y aparecerá un submenu. La opción de Convert To permite generar el metamodelo Ecore. 49

60 Capítulo 4 Definición del metamodelo para la transformación Figura 4.3: Metamodelo mos.ecore 50

61 Capítulo 4 Definición del metamodelo para la transformación El metamodelo mos.ecore servirá para que el editor de MOFScript lo tenga como metamodelo de referencia cuando convierta modelos *.mos a las especificaciones WSDL y BPEL Elementos del metamodelo MOS Ecore mapeados a elementos WSDL Elementos seleccionados del documento WSDL Los elementos listados a continuación ya han sido descritos en la sección Estos elementos han sido seleccionados para realizar la transformación. Cada elemento tiene su correspondencia en elementos del modelo MOS. message part porttype operation binding port El elemento proceso es mapeado a los elementos: definitions, service, port, porttype, y binding. Como ya se mencionó en la sección 4.5.2, un proceso es considerado un servicio, por lo tanto en el nodo definitions se indica el nombre del proceso que representa al servicio. El nodo service es donde se indica el servicio. El nodo port indica la dirección de acceso al servicio, al nombre del proceso se le agrega HttpSoapEndpoint para establecer el nombre del port. El nodo porttype es el contenedor de las operaciones con las que cuenta el servicio. Para establecer el nombre, se usa el nombre del proceso agregando PortType. El nodo binding que es utilizado para asignar el nombre, usa el nombre del proceso agregando SoapBinding. El elemento tarea es mapeado a los elementos WSDL: message y operation. Como los mensajes son los datos transportados su nombre es asignado con el nombre de la tarea, dependiendo si es de petición o respuesta se agrega Request o Response. El nodo operation contiene a cada una de las operaciones del servicio, toma el nombre de la tarea. Por último el elemento recurso es mapeado al elemento part, el cuál indica el tipo de dato usado en el mensaje a ser transportado. En la tabla 4.4 se muestra la correspondencia de los elementos Ecore en elementos WSDL. 51

62 Capítulo 4 Definición del metamodelo para la transformación Tabla 4.4: Correspondencia de elementos MOS a elementos WSDL Elementos del Elementos Ecore Elementos WSDL modelo orientado a servicios Proceso EClass <service> </service> <definitions> <\definitions> <port> </port> <porttype> </porttype> < binding> </ binding> Tarea EClass < message> </ message> <operation> </ operation> Recurso EClass <part/> Elementos del metamodelo MOS Ecore mapeados a elementos BPEL4WS Elementos seleccionados del documento BPEL4WS Algunos de los elementos listados a continuación ya han sido descritos en la sección 2.6.1, pero los elementos como: assign, invoke, receive reply y sequence; son introducidos en esta sección porque forman parte de la actividad de orquestación de servicios Web. Los elementos de la lista han sido seleccionados como elementos básicos de un documento BPEL4WS: partnerlink variable assign invoke receive reply sequence A continuación se describen brevemente los elementos assign, invoke, receive reply y sequence [BEAS03]. assign Es una actividad básica, puede ser usada para copiar datos de una variable a otra, también para construir e insertar nuevos datos usando expresiones. Las expresiones son usadas para ejecutar, por ejemplo, un incremento de número de secuencia. Los tipos de datos de la fuente y el destino deben de ser compatibles. invoke Actividad básica que permite invocar una operación one-way o request-response en un porttype ofrecido por un partner, esto es, una operación de un servicio Web. Puede ser una operación síncrona o asíncrona. 52

63 Capítulo 4 Definición del metamodelo para la transformación receive Actividad básica que especifica el partner link que espera recibir un mensaje por parte de la operación y el puerto que invocó. Además, puede especificar una variable que se utilizará para recibir los datos del mensaje recibidos. Las actividades receive juegan un rol en el ciclo de vida del proceso, ya que la única forma de instanciarlo es colocando el atributo createinstance= yes en la primer actividad del proceso. reply Actividad básica usada para mandar una respuesta a una petición previamente aceptada a través de una actividad receive. sequence Actividad estructurada que contiene una o más actividades (básicas o estructuradas) que se ejecutan de forma secuencial, en el orden en que están definidas dentro del elemento sequence. Una actividad no puede comenzar a ejecutarse hasta que su predecesora haya terminado. El elemento servicio básico es mapeado a los elementos: process, partnerlink, variable. El servicio básico representa a la orquestación de servicios Web, los cuales son representados por los procesos (MOS). Por lo tanto, el elemento process toma el nombre del servicio básico. El servicio básico también se mapea a un partnerlink y variable, el primero porque es el partner cliente que es representado por el servicio y es mapeado a variables de entrada y salida, para dar entrada de datos y obtener el resultado del proceso. El elemento proceso es mapeado al elemento partnerlink, este es usado para indicar los servicios que participan durante las invocaciones de las operaciones involucradas en la orquestación. El elemento tarea es mapeado a variables Invoke InputVariable y OutputVariable. Las tareas son las operaciones de los servicios, también son mapeados al tipo de mensaje intercambiado. Por último, una tarea es mapeada a un elemento, indicando cuál es el elemento a ser asignado o copiado. En la tabla 4.5, se muestra la correspondencia de los elementos Ecore en elementos BPEL4WS. 53

64 Capítulo 4 Definición del metamodelo para la transformación Tabla 4.5: Correspondencia de elementos MOS a elementos BPEL4WS Elementos del Elementos Ecore Elementos BPEL4WS modelo orientado a servicios Servicio básico EClass <process> <\process> <partnerlink/> <variable/> inputvariable outputvariable Proceso EClass <partnerlink/> porttype Tarea EClass <variable/> port Invoke_ _InputVariable Invoke_ _OutputVariable messagetype Recurso EClass Element/ns2: En este capítulo se presentó el análisis para la realización de un metamodelo intermedio basado en un modelo orientado a servicios [ESTR08]. El modelo base requirió modificaciones para obtener un metamodelo que cumpliera con todas las características necesarias, y poder llevar a cabo el mapeo de elementos de forma directa. El metamodelo intermedio resultante es llamado mos.ecore. El metamodelo es necesario para ejecutar una transformación y a partir de mos.ecore se pueden crear modelos *.mos, los cuales serán los modelos de entrada de la herramienta MOFScript. En el siguiente capítulo se presentan las reglas de transformación, estas reglas al ser aplicadas a los modelos *.mos generan los documentos WSDL y BPEL4WS. Las reglas están descritas en el lenguaje de transformación MOFScript. 54

65 Capítulo 5 Reglas de transformación En este capítulo se presentan las reglas de transformación descritas en el lenguaje MOFScript. El objetivo de definir las reglas es usarlas en el plug-in MOFScript de Eclipse, este plug-in las ejecuta y produce las especificaciones correspondientes en WSDL y BPEL4WS. Las reglas están escritas para manipular un modelo *.mos (representado en una estructura XML), la manera en que trabaja una regla es: tomar cada uno de los elementos del modelo y en base a la regla genera el mapeo a los elementos de WSDL y/o BPEL4WS. Las reglas de transformación pueden verse como módulos de un programa que identifica cada uno de los elementos del modelo *.mos, lee sus propiedades y genera una cadena de texto. La cadena de texto está escrita en formato XML y representa el elemento mapeado de un documento WSDL o de un documento BPEL4WS. El plug-in que ejecuta las reglas es MOFScript versión en el IDE Eclipse Las reglas de transformación que se presentan a continuación, fueron diseñadas tomando en cuenta el análisis de los documentos WSDL y BPEL4WS del capítulo 2 así como del análisis del metamodelo intermedio del capítulo 4. 55

66 Capítulo 5 Reglas de transformación 5.1 Reglas de transformación MOS2WSDL Las reglas descritas en esta sección generan cadenas de texto en formato XML para la formación de los documentos WSDL, las cadenas obtenidas están escritas con una estructura establecida por la W3C de los documentos WSDL [W3CN01] y con algunas características agregadas de la estructura que presentan los documentos WSDL generados por Netbeans 6.5. El IDE Netbeans fue seleccionado debido a que muestra una vista amigable de las organización de los documentos WSDL. Las reglas están diseñadas para ser aplicadas a los modelos *.mos Regla principal MOS2WSDL Esta regla es la principal y empieza por la identificación de los procesos contenidos en el modelo *.mos. Por cada proceso se especifica la ruta donde será almacenado el documento WSDL, tomando el nombre del proceso como el nombre del archivo. Esta regla contiene a otras subreglas que serán explicadas a continuación. mmos.serviciobasico::main() { var ruta: String="C:\\PrototipoModelo\\archivos\\servicios\\" self.procesos->foreach(pro:mmos.proceso) { if(pro.transaccional=="t"){ file(ruta + self.nombre.replace(" ", "_") + "\\" + pro.nombre.replace(" ","").tolower() + ".wsdl") print(pro.inicioxml()) print(pro.definitionswsdl()) print(pro.documentationwsdl()) print(pro.typeswsdl()) print(pro.messageswsdl()) print(pro.porttypeswsdl()) print(pro.bindingswsdl()) print(pro.servicewsdl()) print(pro.finxml()) } } Figura 5.1: Regla principal MOS2WSDL Reglas de inicio y fin del documento La regla de inicio coloca al principio del documento la etiqueta que indica que es un documento de tipo XML, la versión y el tipo de codificación del texto, para este caso es UTF-8. La regla fin agrega la última etiqueta que cierra el documento XML con la palabra definitions. Esta regla está asociada al elemento proceso. mmos.proceso::inicioxml() : String { result= '<?xml version="1.0" encoding="utf-8"?> \n' } mmos.proceso::finxml(): String { result = "</definitions>"} Figura 5.2: Reglas de inicio y fin 56

67 Capítulo 5 Reglas de transformación Regla definición del servicio Este regla permite establecer el encabezado del documento WSDL con la etiqueta definitions. La etiqueta definitions está compuesta de atributos como el nombre del servicio, el namespace y otras especificaciones referentes a soap, xsd, bpel y axis. Esta regla es definida a partir del elemento proceso. mmos.proceso::definitionswsdl() : String { var nombreservicio:string = self.nombre.replace(" ", "").tolower() result= '<definitions name="' + nombreservicio + '" targetnamespace=" + nombreservicio + '" xmlns=" xmlns:wsdl=" xmlns:xsd=" xmlns:tns=" nombreservicio + '" xmlns:plnk=" xmlns:soap=" \n' } Figura 5.3: Regla definitionwsdl Regla tipos de datos Esta regla establece el tipo de dato, crea un esquema de datos a usar por el servicio Web. Sin embargo, para esta transformación la regla no es aplicada, ya que los tipos de datos son especificados en la regla mmos.proceso::typeswsdl() : String { var tipos:string= '' tipos = '<types/> \n' result = tipos } Figura 5.4: Regla typeswsdl Regla mensajes transportados Esta regla permite definir los mensajes del documento WSDL. Se apoya de las subreglas messagestype, partsrequest y partsresponse, estas subreglas determinan el tipo de datos que usan y si los mensajes son de respuesta o de petición. Estos mensajes son los que las operaciones de los servicios Web envían o reciben durante un intercambio de información. mmos.proceso::messageswsdl() : String { result = self.messagestype() } Figura 5.5: Regla messageswsdl 57

68 Capítulo 5 Reglas de transformación Subregla tipos de mensajes Esta regla al igual que las anteriores es definida a partir del elemento proceso. En esta regla se determinan si los mensajes son mensajes sólo de petición o de respuesta y petición. A partir de la identificación de las tareas de cada proceso, la regla verifica si la tarea es transaccional, si el valor es T a continuación verifica si es de tipo void. Si es void entonces es sólo un mensaje de petición, en el caso contrario es un mensaje de petición y respuesta. mmos.proceso::messagestype() : String { var messagerequest:string ='' var messageresponse:string ='' var messagetotal:string ='' self.tareas->foreach(t:mmos.tarea){ if(t.transaccional=='t') { if(t.tipo == "void") { messagerequest = '<message name="' + t.nombre.replace(" ", "").tolower() + 'Request"> \n' + t.partsrequest() + '</message> \n' messageresponse = '<message name="' + t.nombre.replace(" ", "").tolower() + 'Response"/> \n' } else { messagerequest = '<message name="' + t.nombre.replace(" ", "").tolower() + 'Request"> \n' + t.partsrequest() + '</message> \n' messageresponse = '<message name="' + t.nombre.replace(" ", "").tolower() + 'Response"> \n' + t.partsresponse(t.tipo)+ '</message> \n' } } messagetotal= messagetotal + messagerequest + messageresponse } result = messagetotal } Figura 5.6: Subregla messagestype Subregla elemento petición Esta subregla toma el valor del atributo tipo del elemento recurso de una tarea específica y lo asigna al atributo type de la etiqueta part del documento WSDL. mmos.tarea::partsrequest(): String { var part:string ='' self.recursos->foreach(r:mmos.recurso) { part = part + '<!--' + r.descripcion + '--> \n' part = part + '<part name="' + r.nombre.replace(" ", "").tolower() + '" type="' + tipodato(r.oclgettype()) + '"/> \n' } result= part } Figura 5.7: Subregla partsrequest 58

69 Capítulo 5 Reglas de transformación Subregla elemento respuesta Esta subregla toma el valor del atributo tipo del elemento tarea y lo asigna al atributo type de la etiqueta part del documento WSDL. mmos.tarea::partsresponse(tipo:string): String { var part:string ='' part = part + '<!--Resultado--> \n' part = part + '<part name="response" type="xsd:' + tipo.tolower() + '"/> \n' result= part } Figura 5.8: Subregla partsresponse Regla lista de operaciones del servicio Esta regla permite establecer la lista de las operaciones del servicio o llamados porttypes de un documento WSDL, a partir de la identificación del elemento proceso. Se apoya de la subregla porttypesoperations, la cual indica la operación y los mensajes de intercambio de información. mmos.proceso::porttypeswsdl() : String { result = '<porttype name="' + self.nombre.replace(" ", "").tolower()+ 'PortType"> \n' + self.porttypesoperations() + '</porttype> \n' } Figura 5.9: Regla porttypeswsdl Subregla operaciones del servicio Esta regla inicia con la identificación del elemento proceso y las tareas que contiene. Por cada tarea se verifica si el atributo transaccional tiene el valor T, si es así, entonces empieza por tomar el nombre del elemento tarea y asignarlo a la operación que ofrece el servicio. mmos.proceso::porttypesoperations(): String { var operation:string ='' self.tareas->foreach(t:mmos.tarea){ if(t.transaccional == "T"){ operation= operation + '<!--' + t.descripcion + '--> \n' operation= operation + '<operation name="' + t.nombre.replace(" ", "").tolower() + '"> \n'+ '<input name="input1" message="tns:' + t.nombre.replace(" ", "").tolower() + 'Request"/> \n' + '<output name="output1" message="tns:' + t.nombre.replace(" ", "").tolower() + 'Response" /> \n' + '</operation> \n'}} result = operation } Figura 5.10: Subregla porttypesoperations 59

70 Capítulo 5 Reglas de transformación Regla protocolo y formato de datos Esta regla permite establecer los bindings del documento WSDL, es decir el protocolo de envío/recepción que en este caso es soap y el estilo de transporte. Se apoya de la subregla bindingsoperations. mmos.proceso::bindingswsdl() : String { result = '<binding name="' + self.nombre.replace(" ", "").tolower() + 'SoapBinding" type="tns:' + self.nombre.replace(" ", "").tolower() + 'PortType"> \n' + '<soap:binding transport=" style="rpc"/> \n' + self.bindingsoperations() + '</binding> \n' } Figura 5.11: Regla bindingswsdl Subregla protocolo soap para las operaciones Esta subregla establece las operaciones del binding, por cada tarea que tenga el valor T en el atributo transaccional se toma como operación del servicio. Además se define también el tipo de protocolo usado para la entrada y salida de los mensajes. mmos.proceso::bindingsoperations(): String { var operation:string ='' self.tareas->foreach(t:mmos.tarea){ if(t.transaccional== "T"){ operation= operation + '<operation name="' + t.nombre.replace(" ", "").tolower() + '"> \n' + '<soap:operation/> \n' + ' <input name="input1"> \n' + ' <soap:body use="literal" namespace=" + self.nombre.replace(" ", "").tolower() + '"/> \n' + ' </input> \n' + ' <output name="output1"> \n' + ' <soap:body use="literal" namespace=" + self.nombre.replace(" ", "").tolower() + '"/> \n' + ' </output> \n' + '</operation> \n' } } result = operation } Figura 5.12: Subregla bindingsoperations 60

71 Capítulo 5 Reglas de transformación Regla servicio Web Esta regla toma el elemento proceso para representar al servicio Web, dentro de la etiqueta service se asigna el nombre del proceso a la propiedad name. En esta etiqueta se encuentra contenida la etiqueta port la cual a su vez contiene la etiqueta soap:address en donde se debe asignar la dirección del servidor donde se encuentra hospedado el servicio. Esta dirección debe ser reemplazada, en la práctica, por un localhost habilitado para hospedar a los servicios Web generados. mmos.proceso::servicewsdl(): String { result = '<service name="' + self.nombre.replace(" ", "").tolower() + '"> \n' + '<port name="' + self.nombre.replace(" ", "").tolower() + 'HttpSoapEndpoint" binding="tns:' + self.nombre.replace(" ", "").tolower() + 'SoapBinding"> \n' + '<soap:address location=" + self.nombre.replace(" ", "").tolower() + '/'+ self.nombre.replace(" ", "").tolower() + 'HttpSoapEndpoint/"/> \n' + '</port> \n' + '</service> \n' } Figura 5.13: Regla servicewsdl 5.2 Reglas de transformación MOS2BPEL Las reglas descritas en esta sección generan cadenas de texto en formato XML para la formación de los documentos BPEL, las cadenas obtenidas están escritas con una estructura establecida por BEA Systems de los documentos BPEL [BEAS03] y con algunas características agregadas de la estructura que presentan los documentos BPEL generados por JDeveloper 11g [ORAC09]. Las reglas están diseñadas para ser aplicadas a los modelos *.mos Regla principal MOS2BPEL Esta regla es la principal y empieza por la identificación de los servicios básicos contenidos en el modelo *.mos. Por cada servicio se especifica la ruta donde será almacenado el documento BPEL, tomando el nombre del servicio como el nombre del archivo. Esta regla contiene otras subreglas que serán explicadas a continuación. mmos.serviciobasico::main () { var ruta: String="C:\\PrototipoModelo\\archivos\\servicios\\" file(ruta + self.nombre.replace(" ", "_") + "\\" + self.nombre.replace(" ","").tolower() + ".bpel") print(inicioxml()) print(self.processbpel()) print(self.partnerlinksbpel()) print(self.variablesbpel()) print(self.orchestrationbpel()) print(finxml())} Figura 5.14: Regla principal MOS2BPEL 61

72 Capítulo 5 Reglas de transformación Reglas de inicio y fin del documento La regla de inicio coloca al principio del documento la etiqueta que indica que es un documento de tipo XML, la versión y el tipo de codificación del texto, para este caso es UTF-8. La regla fin agrega las últimas dos etiquetas que cierran el documento XML, con las palabras sequence y process. module::inicioxml() : String { result = '<?xml version="1.0" encoding="utf-8"?> \n' + '<!-- PROCESO BPEL -->' } module::finxml() : String { result = '</sequence> \n' + '</process>' } Figura 5.15: Reglas de inicio y fin Regla definición del proceso Esta regla inicia con la identificación del elemento servicio básico. Esta regla permite establecer el encabezado del documento BPEL con la etiqueta process. La etiqueta process está compuesta de atributos como el nombre del proceso, el namespace y otras URL necesarias. Esta regla es definida a partir del elemento servicio básico. mmos.serviciobasico::processbpel() : String { result = '<process name="' + self.nombre.replace(" ","").tolower() + '" \n' + 'targetnamespace= " + self.nombre.replace(" ","").tolower() + '" \n' + 'xmlns=" \n' + 'xmlns:xsd=" \n' + 'xmlns:bpws=" \n' + 'xmlns:xp20=" tions.xpath20" \n' + 'xmlns:ns1=" + self.nombre.replace(" ","").tolower() + '/" \n' + 'xmlns:ldap=" \n' + 'xmlns:ns2=" + self.nombre.replace(" ","").tolower() + '/types/" \n' + 'xmlns:bpelx=" \n' + 'xmlns:client=" self.nombre.replace(" ","".tolower())+ '" \n' + 'xmlns:ora=" \n' + 'xmlns:orcl=" tions.extfunc"> \n' } Figura 5.16: Regla processbpel 62

73 Capítulo 5 Reglas de transformación Regla lista de servicios participantes Esta regla es definida a partir del elemento servicio básico. En esta regla se especifican los servicios que participan en el proceso de orquestación de servicios, cada servicio Web es un partnerlink que será invocado a través de la orquestación. Esta regla se apoya de la subregla partners. mmos.serviciobasico::partnerlinksbpel() : String { result = '<!-- PARTNERLINKS --> \n' + '<!-- Lista de servicios que participan en el proceso BPEL --> \n' + '<partnerlinks> \n' + '<!-- El rol "cliente" representa al solicitante del servicio --> \n' + '<partnerlink name="client" partnerlinktype="client:' + self.nombre.replace(" ","").tolower() + '" \n' + ' myrole="' + self.nombre.replace(" ","").tolower() + 'Provider"/> \n' + self.partners() + '</partnerlinks>' } Figura 5.17: Regla partnerlinksbpel Subregla servicios participantes Esta regla inicia con la identificación del servicio básico y de los procesos contenidos en él. De cada proceso se verifica el atributo transaccional, si el valor es T se toma en cuenta para agregarse como elemento partnerlink. mmos.serviciobasico::partners() : String { var partner:string ='' var orden:integer =1 self.procesos->foreach(p:mmos.proceso){ if(p.transaccional=="t"){ if(p.ordenejecucion==orden){ partner = partner + '<partnerlink myrole="' + p.nombre.replace(" ", "").tolower() + '_Role" name="' + p.nombre.replace(" ", "").tolower() + '" \n' + ' partnerrole="' + p.nombre.replace(" ","").tolower() + '_Role" \n' + ' partnerlinktype="ns1:' + p.nombre.replace(" ","").tolower() + '_PL"/> \n' } } orden= orden + 1 } result = partner } Figura 5.18: Subregla partners 63

74 Capítulo 5 Reglas de transformación Regla variables involucradas Esta regla comienza por identificar las variables de entrada y salida de datos, a través del uso del elemento servicio básico como punto de entrada. Esta regla se apoya de la subregla variables para determinar las variables usadas por cada servicio que interactúa en la orquestación. mmos.serviciobasico::variablesbpel() : String { result = '<!-- VARIABLES \n' + ' Lista de mensajes y documentos XML usados dentro del proceso BPEL --> \n' + '<variables> \n' + '<!-- Referencia al mensaje pasado como entrada durante la iniciación--> \n' + '<variable name="inputvariable" \n' + ' messagetype="client:' + self.nombre.replace(" ", "").tolower() + 'RequestMessage"/> \n' + '<!-- Referencia al mensaje que será regresado al solicitante--> \n' + '<variable name="outputvariable" \n' + ' messagetype="client:' + self.nombre.replace(" ", "").tolower() + 'ResponseMessage"/> \n' + self.variables()+ '</variables> \n' } Figura 5.19: Regla variablesbpel Subregla variables Esta regla inicia con la identifición del elemento de entrada servicio básico. Por cada elemento proceso contenido en el servicio básico se obtienen las tareas asociadas al proceso. El primer paso es verificar que el atributo transaccional del elememto proceso sea T. También se debe obtener el atributo ordenejecucion del elemento proceso para establecer la secuencia de aparición de los servicios. Después se obtienen las tareas del proceso y se verifica que el atributo transaccional de la tarea sea igual a T, además se validan los atributos tipo y ordenejecucion del elemento y se asigna el nombre de la tarea a la propiedad name de la etiqueta variable. mmos.serviciobasico::variables() : String { var variable:string ='' var ordenp:integer = 1 var ordent:integer = 1 var orden:integer = 1 self.procesos->foreach(p:mmos.proceso){ if(p.transaccional=="t"){ if(p.ordenejecucion==ordenp){ orden=1 p.tareas->foreach(t:mmos.tarea){ if(t.transaccional=="t"){ if(t.tipo!= "void"){ if(t.ordenejecucion==orden){ variable= variable + '<variable name="invoke_' + ordent + '_' + t.nombre.replace(" ", "").tolower() + 64

75 Capítulo 5 Reglas de transformación '_InputVariable" \n' + ' messagetype="ns1:' + t.nombre.replace(" ", "").tolower() + 'Request"/> \n' + '<variable name="invoke_' + ordent + '_' + t.nombre.replace(" ", "").tolower() + '_OutputVariable" \n' + ' messagetype="ns1:' + t.nombre.replace(" ", "").tolower() + 'Response"/> \n' } } } ordent= ordent + 1 orden= orden + 1 } } } ordenp= ordenp + 1 } result = variable } Figura 5.20: Subregla variables Regla orquestación de servicios Esta regla inicia con la identificación del elemento servicio básico y establece la secuencia de ejecución de los servicios dentro del proceso de orquestación. La orquestación se realiza a través de la asignación de variables y la invocación de servicios Web. Se apoya de las subreglas assign e invoke. El proceso es síncrono ya que sólo permite crear secuencialmente la invocación de los servicios. mmos.serviciobasico::orchestrationbpel() : String { var ordenassign:integer = 1 var vartarea:string='' var ordenp:integer = 1 var ordent:integer = 1 var orden:integer = 1 var proceso:string ='' proceso = '<!-- LOGICA DE LA ORQUESTACION \n' + ' Conjunto de actividades coordinando el flujo de mensajes a traves de los \n ' + ' servicios integrados dentro del proceso de negocio --> \n' + '<sequence name="main"> \n' + '<!-- Recibe la entrada del solicitante --> \n' + '<receive name="receiveinput" partnerlink="client" \n' + ' porttype="client:' + self.nombre.replace(" ", "").tolower() + '" operation="process" \n' + ' variable="inputvariable" createinstance="yes"/> \n' self.procesos->foreach(p:mmos.proceso){ if(p.transaccional=="t"){ orden=1 p.tareas->foreach(t:mmos.tarea){ if(t.transaccional=="t"){ if(t.tipo!= "void"){ proceso = proceso + '<assign name="assign_' + ordenassign + '"> \n' t.recursos->foreach(r:mmos.recurso){ if(p.ordenejecucion==ordenp){ 65

76 Capítulo 5 Reglas de transformación if(t.ordenejecucion==orden){ if(ordenassign==1){ proceso = proceso + assign('inputvariable','payload','/client:' + self.nombre.replace(" ", "").tolower() + 'ProcessRequest/client:input', 'Invoke_' + ordent + '_' + t.nombre.replace(" ", "").tolower() + '_InputVariable', 'parameters', '/ns2:'+ t.nombre.replace(" ", "").tolower() + 'Element/ns2:' + r.nombre.replace(" ","").tolower()) vartarea = t.nombre.replace(" ", "").tolower() } else{ proceso= proceso + assign('invoke_' + (ordent-1) + '_' + vartarea + '_OuputVariable','parameters','/n2:' + vartarea + 'ResponseElement/ns2:result', 'Invoke_' + ordent + '_' + t.nombre.replace(" ", "").tolower() + '_InputVariable', 'parameters', '/ns2:'+ t.nombre.replace(" ", "").tolower() + 'Element/ns2:' + r.nombre.replace(" ","").tolower()) vartarea = t.nombre.replace(" ", "").tolower() } } } } proceso= proceso + '</assign> \n' proceso = proceso + invoke(ordent,p.nombre.replace(" ", "").tolower(),'ns1:' + p.nombre.replace(" ", "").tolower(), t.nombre.replace(" ", "").tolower(),'invoke_' + ordent + '_' + t.nombre.replace(" ", "").tolower() + 'InputVariable','Invoke_' + ordent + '_' + t.nombre.replace(" ", "").tolower() + 'OuputVariable') } } ordenassign = ordenassign + 1 ordent = ordent + 1 orden = orden + 1 } } ordenp = ordenp + 1 } proceso = proceso + '<assign name="assign_' + ordenassign + '"> \n' proceso = proceso + assign('invoke_' + (ordent-1) + '_' + vartarea + '_OuputVariable', 'parameters','/n2:' + vartarea + 'ResponseElement/ns2:result','outputVariable','payload','/client:' + self.nombre.replace(" ", "").tolower() + 'ProcessResponse/client:result') proceso = proceso + '</assign> \n' proceso = proceso + '<reply name="replyout" partnerlink="client" \n' + ' porttype="client:' + self.nombre.replace(" ", "").tolower() + '" operation="process" \n' + ' variable="outputvariable"/>' result = proceso } Figura 5.21: Regla orchestrationbpel 66

77 Capítulo 5 Reglas de transformación Subregla asignación de valores de las variables Esta regla permite copiar los valores de las variables involucradas en el proceso de orquestación, asigna el valor de una variable origen y lo copia a una variable destino. module::assign(var1:string, part1:string, query1:string, var2:string, part2:string, query2:string) : String { result= ' <copy> \n' + ' <from variable="' + var1 + '" part="' + part1 + '" \n' + ' query="' + query1 + '"/> \n' + ' <to variable="' + var2 + '" part="' + part2 + '" \n' + ' query="' + query2 + '"/> \n' + ' </copy> \n' } Figura 5.22: Subregla assign Subregla invocación de servicios Esta regla permite hacer la invocación de las operaciones contenidas en los servicios que participan en el proceso de orquestación. module::invoke(num:string, partner:string, port:string, operation:string, input:string, output:string) : String { result='<invoke name="invoke_' + num + '" partnerlink="' + partner + '" \n' + ' porttype="' + port + '" operation="' + operation + '" \n' + ' inputvariable="' + input + '" \n' + ' outputvariable="' + output + '"/> \n' } Figura 5.23: Subregla invoke En este capítulo se presentaron las reglas de transformación que permiten la obtención de los documentos WSDL y BPEL. Las reglas están escritas con el lenguaje MOFScript, el cuál además de ser un lenguaje es una herramienta de transformación. Las reglas fueron diseñadas para convertir modelos *.mos en especificaciones WSDL de servicios Web y en documentos BPEL para establecer la orquestación de servicios Web. Las reglas pueden ser ejecutadas con el plug-in MOFScript de Eclipse versión 3.3.2, tomando como entrada modelos *.mos creados previamente en el prototipo que se desarrolló, como apoyo, en esta tesis. En el siguiente capítulo se presenta el análisis y el diseño que se llevó a cabo para desarrollar el prototipo de modelado mencionado. 67

78 Capítulo 6 Análisis y diseño del prototipo A continuación se presentan los casos de uso del prototipo que implementa el modelo definido en la sección Estos elementos son los necesarios para obtener el modelo MOS en XML y producir los documentos WSDL y BPEL aplicando las reglas de transformación en MOFScript. 6.1 Diagramas de casos de uso A continuación se presenta el análisis de requerimientos y diseño del prototipo MOS, modelado con diagramas de casos de uso, de secuencia y de actividad. Para realizar esta etapa se utilizó el lenguaje de modelado unificado UML. En la figura 6.1 se muestra el diagrama general de casos de uso del prototipo MOS. Son dos casos de uso principales: Modelar servicios de una organización y Generar modelo MOS. 68

79 Capítulo 6 Análisis y diseño del prototipo Prototipo modelador de servicios CU_1 Modelar servicios de una organización Usuario CU_2 Generar modelo MOS Figura 6.1: Diagrama general de casos de uso Cada uno de los casos de uso principales representan las funciones que puede realizar el usuario utilizando el sistema. Estas opciones son las necesarias para obtener el modelo MOS, el cual es necesario para aplicar las reglas de transformación. Cada caso de uso principal es detallado en los casos de uso incluídos o los casos de uso que lo extienden. A continuación se muestran los diagramas de cada caso de uso. En la figura 6.2 se muestra el caso de uso Modelar servicios de una organización, este corresponde a la etapa de definición de los servicios que son ofrecidos por una organización. Los casos de uso necesarios para realizar el modelado son: Modelar servicio compuesto, Modelar servicio básico, Modelar procesos y Modelar protocolo. Los casos de uso anteriores corresponden a modelar los elementos que son requeridos para obtener el modelo MOS (elementos analizados en la sección 4.5.2). 69

80 Capítulo 6 Análisis y diseño del prototipo CU_1.1 Modelar serv icio compuesto «include» CU_1.2 Modelar servicio básico CU_1 Modelar serv icios de una organización «include» Usuario «include» «include» CU_1.3 Modelar procesos CU_1.4 Modelar protocolo Figura 6.2: Diagrama del caso de uso CU_1 Modelar servicios de una organización En la figura 6.3 se muestra el diagrama del caso de uso Generar modelo MOS el cual se apoya de los subcasos de uso Identificar propiedades de los elementos MOS y Guardar información del modelo. CU_ 2.1 Identificar propiedades de los elementos MOS CU_ 2 Generar modelo MOS «include» Usuari o «extend» CU_ 2.2 Guardar información del modelo Figura 6.3: Diagrama del caso de uso CU_2 Generar modelo MOS 70

81 Capítulo 6 Análisis y diseño del prototipo El subcaso de uso Identificar propiedades de los elementos MOS es requerido por el caso de uso Generar modelo MOS. El establecimiento de las propiedades que contienen los elementos servirá para generar el modelo MOS en XML y posteriormente éste debe ser guardardo con toda la información. La descripción completa de los escenarios de éxito y fracaso de estos casos de uso junto con los diagramas de actividad se encuentran en el Anexo A de esta tesis. 6.2 Diagramas de secuencia La figura 6.4 muestra el diagrama de secuencia general representando el caso de uso Modelar servicios de una organización. El usuario crea el modelo ingresando los datos de nombre y descripción, posteriormente lo selecciona y agrega los servicios deseados. El usuario continúa agregando los elementos que conforman a los servicios y el modelo se representa como una estructura de árbol. Los servicios cuentan con las propiedades de nombre, descripción y orden de ejecución y no son agregados al modelo hasta que el usuario haya ingresado las propiedades correctamente. Los dos tipos de servicios que pueden ser modelados son los servicios compuestos y los servicios básicos, es necesario hacer notar que existe un diagrama de secuencia para el modelado de cada uno. El modelado de los procesos se realiza después de haber agregado los servicios básicos, debido a que los procesos van contenidos dentro de éstos. Por último se agregan las tareas y los recursos, los cuales van contenidos dentro de los procesos. 71

82 Capítulo 6 Análisis y diseño del prototipo FrmPrincipal arbol cbelemento Control ElementoMOS Usuario crearmodelo() nuevo() nuevo() getselecteditem() new() :modelo agregarelemento() agregar() nuevo() getselecteditem() new() :servicio compuesto agregarelemento() nuevo() getselecteditem() new() :servicio basico agregarelemento() agregar() nuevo() getselecteditem() new() :proceso agregarelemento() agregar() nuevo() getselecteditem() new() :tarea agregarelemento() agregar() nuevo() getselecteditem() new() :recurso agregarelemento() Figura 6.4: Diagrama de secuencia del caso de uso CU_1 Modelar servicios de una organización 72

83 Capítulo 6 Análisis y diseño del prototipo El caso de uso generar el modelo MOS, se observa en el diagrama de secuencia de la figura 6.5. Se observa la participación de los objetos Analizador y Archivo que son controlados a través del objeto Control, el cual recibe la orden a través del frame FrmPrincipal, con el cual interactúa el usuario. Los diagramas de secuencia completos están descritos en el Anexo B de esta tesis. FrmPrincipal Control Analizador Archivo Usuario generarmodelo() generarmos() comprobarcompletitud() mapearxml() mos XML() guardarinformacion() guardarmos() guardar() Figura 6.5: Diagrama de secuencia del caso de uso CU_2 Generar modelo MOS 73

84 Capítulo 6 Análisis y diseño del prototipo 6.3 Diagrama de clases La arquitectura de clases que se diseño para el prototipo está basado en el patrón Modelo- Vista-Control (MVC), a continuación se muestran los paquetes de cada uno de estos elementos del patrón. pckvista JFrame JLabe l 1..* 1..* 1 + main() : void 1..* 0..* JTex tfield 1 + settext() : void 1..* FrmPrincipa l + main() : void txtnombre txtdescripcion txtordene + settext() : void + settext() : void + settext() : void JButton 1..* + actionperformed() : void JComboBox + getselecteditem() : String + itemstatechanged() : void 1.. * btnagregar + actionperformed() : void btneliminar + actionperformed() : void cbelemento cbtipo + getselecteditem() : String + itemstatechanged() : void + getselecteditem() : String + itemstatechanged() : void btnmodificar + actionperformed() : void btnaceptar + actionperformed() : void cbtransaccion + getselecteditem() : String + itemstatechanged() : void btncancelar + actionperformed() : void Figura 6.6: Paquete de la vista (A) El patrón de la figura 6.6 y figura 6.7 muestra como está integrada la vista de diseño del prototipo, es decir, la ventana principal, botones, etiquetas, campos de texto, combos, menús y demás elementos que lo componen. 74

85 Capítulo 6 Análisis y diseño del prototipo pckvista mnumodelo + add(jmenuitem) : void JMenuBar JMenu + add(jmenu) : void * + add(jmenuitem) : void FrmPrincipa l + main() : void 1.. * 1.. * JMenuItem + actionperformed() : void mnugenera r + add(jmenuitem) : void 1 JTabbedPane + addtab() : void 1 1 JPane l JTex tpane mnuiabrirm + settext() : void + actionperformed() : void mnuimodelomos + actionperformed() : void mnuiguardarm + actionperformed() : void Figura 6.7: Paquete de la vista (B) pckcontrol Control - analiza: Analizador - archivo: Archivo + abrirmos() : void + agregarelemento() : void + agregarmodelo() : void + crearelemento() : ElementoMOS + eliminarelemento() : void + generarmos() : void + guardarmos() : void + modificarelemento() : void + modificarmodelo() : void + nuevomos() : void + transformarmos() : void Figura 6.8: Paquete del control 75

86 Capítulo 6 Análisis y diseño del prototipo El paquete del control recibe las acciones y las realiza, llamando a su vez al paquete del modelo para llevar a cabo la ejecución de lo indicado por la vista. El paquete del modelo contiene la lógica del prototipo de modelado. pckmodelo - descripcion: String - element: Element - elemento: String - nombre: String - ordenejecucion: int - tipo: String - transaccional: String ElementoMOS + getdescripcion() : String + getelemento() : String + getnombre() : String + getordene() : int + gettipo() : String + gettransaccional() : String + setdescripcion(string) : void + setelemento(string) : void + setnombre(string) : void + setordene(int) : void + settipo(string) : void + settransaccional(string) : void Analizador + comprobarcompletitud(treemodel) : boolean + verificarrepeticion(treemodel, String) : boolean 1 XMLTreeNode + getelement() : Element + gettext() : String + tostring() : String 1 1..* XMLTreeModel 1 1 Archiv o + abrir(string, JTree) : DefaultTreeModel + generarmosxml(treemodel) : JTextPane + guardar(treemodel, String) : void - procesalinea(treemodel, OutputStreamWriter) : void - reconstruirmodelo(xmltreemodel, JTree) : void - recorrearbol(treemodel, JTextPane) : void «enumeration» Transaccion + tostring() : String «enumeration» Elemento + tostring() : String «enumeration» Tipo + tostring() : String + addtreemodellistener(treemodellistener) : void + getchild(int, Object) : Object + getchildcount(object) : int - getchildelements(node) : Vector <Element> + getdocument() : Document + getindexofchild(object, Object) : int + getroot() : Object + isleaf(object) : boolean + removetreemodellistener(treemodellistener) : void + setdocument(document) : void + valueforpathchanged(object, TreePath) : void Figura 6.9: Paquete del modelo En este capítulo se presentó el análisis y diseño del prototipo que permite crear los modelos *.mos. El prototipo es sólo una herramienta que utiliza el usuario para alcanzar el objetivo de este trabajo de investigación: la generación de las especificaciones WSDL de servicios Web a partir de los modelos organizacionales orientados a servicios. Es importante enfatizar que los modelos *.mos que se generan a través del uso del prototipo están basados en el análisis realizado en el capítulo 4. Sin embargo, el análisis y diseño del prototipo fue establecido de acuerdo a las necesidades de la investigación como: a) permitir un modelado sencillo en estructura de árbol; b) contar con los elementos MOS para ser modelados; c) usar la lógica de modelado establecida en el trabajo [ESTR08]; d) permitir la generación de los modelos MOS; e) permitir la ejecución de las reglas de transformación. De acuerdo a las necesidades mencionadas es como se diseñaron los casos de uso y la interfaz del prototipo. El siguiente capítulo describe la interfaz de prototipo y las funcionalidades. También se presentan la implementación y las pruebas que fueron realizadas para validar el trabajo de investigación y la obtención del objetivo propuesto. 76

87 Capítulo 7 Implementación y pruebas En este capítulo se presenta la implementación del prototipo, aplicando el análisis y diseño realizado en el capítulo anterior. Además se describe el plan de pruebas realizado para comprobar que el objetivo de la tesis se obtuvo correctamente, conforme a los alcances y limitaciones que fueron expuestos en el capítulo Implementación del prototipo El prototipo de modelado se desarrolló utilizando Java, usando NetBeans IDE 6.5. El prototipo permite modelar servicios, procesos, tareas y recursos. Estos elementos son los necesarios para representar los servicios expuestos por una organización. Las funcionalidades con las que cuenta el prototipo son: 1) crear un modelo de servicios; 2) abrir modelos existentes; 3) generar el modelo MOS en XML; 2) guardar el modelo como archivo *.mos y 4) ejecución de Eclipse V para aplicar las reglas de transformación usando el plug in de MOFScript. 77

88 Capítulo 7 Implementación y pruebas A continuación se muestra el diseño de la ventana principal (ver figura 7.1) así como la descripción de los componentes integrados, la ventana es divida en secciones que son descritas brevemente: (1) (2) (3) (4) (5) (6) (7) Figura 7.1: Ventana principal del prototipo (8) Sección (1) Menú principal, compuesto por los menús Modelo, Generar, MOFScript y Archivos. El menú Modelo se descompone en los siguientes submenús: 78 o Nuevo, permite crear un nuevo modelo. o Abrir, permite abrir un modelo existente. o Cerrar, permite cerrar el modelo en pantalla.

89 Capítulo 7 Implementación y pruebas El menú Generar se descompone en los siguientes submenús: o Modelo MOS XML, permite generar el esquema del modelo en XML. o Guardar modelo MOS, permite guardar como archivo *.mos el modelo en pantalla. El menú MOFScript se descompone en el siguiente submenú: o Transformar, permite ejecutar Eclipse V para ejecutar las reglas de transformación. El menú Archivos se descompone en los siguientes submenús: o Modelos MOS, permite abrir el explorador para visualizar los archivos guardados. o Documentos WSDL y BPEL, permite abrir el explorador para visualizar los archivos generados a partir de ejecutar las reglas de transformación. Sección (2) Es un TabPane que contiene dos tabs, el primero muestra el modelo gráficamente en forma de árbol y el segundo tab muestra el modelo en su representación XML. Sección (3) Se compone de campos de texto que son usados para ingresar el nombre y la descripción del modelo. Sección (4) Botones de Agregar y Modificar. El primero agrega el modelo y el segundo permite modificar las propiedades. 79

90 Capítulo 7 Implementación y pruebas Sección (5) Conjunto de etiquetas que despliegan la información del elemento seleccionado en el modelo. Sección (6) Botones de Eliminar y Modificar. El primero elimina un elemento del modelo y el segundo permite modificar las propiedades. En ambos casos la acción es sobre el elemento seleccionado en el modelo. Sección (7) Conjunto de combos y campos de texto. El combo de elemento muestra los diferentes tipos de elementos MOS que pueden ser agregados al modelo. Los demás componentes de esta sección están asociados a las propiedades correspondientes al elemento seleccionado del combo Elemento. Sección (8) Botón de Agregar. Permite agregar los elementos al modelo. 7.2 Aplicación de las pruebas en el prototipo En esta sección se presentan las características probadas y la aplicación de los casos de prueba en el prototipo Descripción de las características probadas Las características que han sido probadas con cada uno de los casos de prueba son: 1) el número de documentos WSDL generados a partir del modelo creado en el prototipo y de la aplicación de las reglas de transformación; 2) el número de operaciones contenidas en el documento WSDL; 3) la generación de un documento BPEL por cada caso de prueba del modelo creado. Tanto el número de documentos WSDL como el número de operaciones contenidas en los documentos varía conforme al caso de prueba. En la siguiente sección se presentan los casos de prueba y por cada uno se especifica el número de documentos WSDL que se esperan obtener, al igual que el número de operaciones por documento Prueba No. 1 Características probadas Las características probadas con esta prueba son: generación de dos documentos WSDL, cada uno debe contener una operación y cada operación debe tener como parámetro un elemento. Además se debe generar un documento BPEL pagolicencia.bpel que realice la orquestación de los servicios. La aplicación de la prueba No.1 es ModeloPrueba1 (figura 7.2). 80

91 Capítulo 7 Implementación y pruebas Figura 7.2: ModeloPrueba1 Evaluación del resultado esperado Éxito: se considera como prueba exitosa si se obtienen los documentos WSDL y BPEL esperados y éstos son validados por la herramienta NetBeans IDE 6.5 y son generados correctamente. Fracaso: se considera como prueba de fracaso si no se obtienen los documentos esperados Prueba No. 2 Características probadas Las características probadas con esta prueba son: generación de un documento WSDL, el cual debe contener dos operaciones y cada operación debe tener como parámetro un elemento. Además se debe generar un documento BPEL tramitarrenovacion.bpel que realice la orquestación de las operaciones del servicio. La aplicación de la prueba No.2 es ModeloPrueba2 (figura 7.3). Figura 7.3: ModeloPrueba2 Evaluación del resultado esperado Éxito: se considera como prueba exitosa si se obtienen los documentos WSDL y BPEL esperados y éstos son validados por la herramienta NetBeans IDE 6.5 y son generados correctamente. Fracaso: se considera como prueba de fracaso si no se obtienen los documentos esperados. 81

92 Capítulo 7 Implementación y pruebas Prueba No. 3 Características probadas Las características probadas con esta prueba son: generación de un documento WSDL, el cual debe contener una operación y cada operación debe tener como parámetro un elemento. La aplicación de la prueba No.3 es ModeloPrueba3 (figura 7.4). Figura 7.4: ModeloPrueba3 Evaluación del resultado esperado Éxito: se considera como prueba exitosa si se obtienen los documentos WSDL esperados y éstos son validados por la herramienta NetBeans IDE 6.5 y son generados correctamente. Fracaso: se considera como prueba de fracaso si no se obtienen los documentos esperados Prueba No. 4 Características probadas Las características probadas con esta prueba son: generación de tres documentos WSDL, los cuales deben contener una operación cada uno, y una de las operaciones tiene como parámetros dos elementos. Además se debe generar un documento BPEL realizarpago.bpel que realice la orquestación de los servicios. La aplicación de la prueba No.4 es ModeloPrueba4 (figura 7.5). Figura 7.5: ModeloPrueba4 82

93 Capítulo 7 Implementación y pruebas Evaluación del resultado esperado Éxito: se considera como prueba exitosa si se obtienen los documentos WSDL y BPEL esperados y éstos son validados por la herramienta NetBeans IDE 6.5 y son generados correctamente. Fracaso: se considera como prueba de fracaso si no se obtienen los documentos esperados Prueba No. 5 Características probadas Las características probadas con esta prueba son: generación de tres documentos WSDL, los cuales deben contener una operación cada uno, y una de las operaciones tiene como parámetros dos elementos, las otras operaciones cuentan con un parámetro. Además se debe generar un documento BPEL prepararenvio.bpel que realice la orquestación de los servicios. La aplicación de la prueba No.5 es ModeloPrueba5 (figura 7.6). Figura 7.6: ModeloPrueba5 Evaluación del resultado esperado Éxito: se considera como prueba exitosa si se obtienen los documentos WSDL y BPEL esperados y éstos son validados por la herramienta NetBeans IDE 6.5 y son generados correctamente. Fracaso: se considera como prueba de fracaso si no se obtienen los documentos esperados. 7.3 Resultados obtenidos de la ejecución del plan de pruebas Los resultados de la ejecución del plan de pruebas corresponden a las descripciones de los servicios en sus correspondientes archivos WSDL, los cuales pueden ser usados para la generación de servicios Web. Los documentos BPEL obtenidos pueden usarse por su estructura, como una guía de cómo debe realizarse la orquestación de los servicios Web. 83

94 Capítulo 7 Implementación y pruebas Como se puede observar en la tabla 7.1, al aplicar las reglas de transformación se obtuvieron los archivos WSDL y BPEL correspondientes a las pruebas realizadas. La excepción fue la prueba número 3, se esperaba obtener un documento BPEL pero no había razón lógica de crearlo debido a que sólo se contaba con un servicio y una operación, es por ello que no se aplicaron las reglas de transformación de MOS2BPEL para crear el documento. La aplicación de las reglas de transformación (específicamente MOS2BPEL) es de acuerdo al criterio del modelador para crear una orquestación de servicios. Ya que en el caso de la prueba número 3, sólo se contaba con un proceso que contiene a una tarea, razón por la cual no se consideró crear el documento BPEL correspondiente. La descripción detallada de los casos de prueba que han sido planteados en este capítulo, se encuentra en el Anexo C. 84

95 Capítulo 7 Implementación y pruebas Tabla 7.1: Resumen del plan de pruebas Prueba Modelo Entrada Generación de WSDL Salida Cantidad Nombre Generación de BPEL Cantidad Obtenidos Esperados Salida Obtenidos Esperados Nombre 1 ModeloPrueba1.mos 2 2 ModeloPrueba2.mos 1 3 ModeloPrueba3.mos 1 4 ModeloPrueba4.mos 3 5 ModeloPrueba5.mos 3 2 encontrarcosto.wsdl registrarpago.wsdl 1 1 renovardatos.wsdl 1 1 checarinventario.wsdl registrarcliente.wsdl registrarpago.wsdl enviaralmacen.wsdl registrardireccion.wsdl eliminardeinventario.wsdl guiadeembarque.wsdl pagolicencia.bpel 1 tramitarrenovacion.bpel 0 1 realizarpago.bpel 1 prepararenvio.bpel Análisis de resultados En todas las pruebas el resultado obtenido fue exitoso a pesar de que la prueba número 3 no generó el documento BPEL4WS, la razón por la cual no se obtuvo el documento es porque no se aplicó la transformación. La obtención o ausencia de documentos BPEL4WS está muy ligada a la decisión del usuario, ya que si él no desea crearlo éste no se generará. Otro de los factores que pueden influir en el modelado es la lógica aplicada para crear el modelo, ya que influirá mucho en que se generen correctamente los documentos WSDL y por consecuencia también el servicio Web. Si en el modelo se configura de forma inadecuada un elemento, por ejemplo, si una tarea con tipo de dato String sea configurada como void ocasionará que al momento de crear el servicio Web a partir de la especificación WSDL la operación del servicio no esté habilitada para retornar un elemento de tipo String (este es uno de los muchos casos que pueden suceder). Las pruebas aplicadas en el prototipo fueron evaluadas de acuerdo a la cantidad esperada de documentos, una validación para que los documentos WSDL estén bien formados (realizada con el programa NetBeans IDE 6.5) y la verificación icación de correspondencia de elementos modelados con los elementos del documentos WSDL. 85

96 Conclusiones El objetivo principal de esta tesis fue la generación de especificaciones WSDL a partir de modelos organizacionales orientados a servicios, el cual se ha conseguido. La metodología propuesta para la generación de las especificaciones considera un enfoque MDA (Model Driven Architecture), el cual involucra el manejo de varias tecnologías y especificaciones que la OMG (Object Management Group) acepta y reconoce por su factibilidad. El trabajar con varias tecnologías y especificaciones es complicado, sin embargo el resultado obtenido es considerado confiable, permitiendo un trabajo que cumple con todas las características deseadas tanto por el usuario como por las organizaciones reconocidas en el desarrollo de software. El utilizar el enfoque MDA implicó trabajar con MOF (estándar de MDA para definir diferentes tipos de lenguajes de modelado), así como también trabajar con lenguajes y herramientas de transformación, entre otras tecnologías. 86

97 Conclusiones Una de las premisas de esta tesis fue el considerar que el modelo orientado a servicios contaba con las características necesarias para permitir una suave transición entre los modelos de negocio y los servicios Web, sin embargo el análisis profundo permitió determinar que se requería modificar el modelo para lograr la generación de las especificaciones WSDL. Como producto del análisis se llegó al acuerdo de introducir un metamodelo intermedio, el cual fue llamado MOS (por sus siglas en español de Modelo Orientado a Servicios). Como resultado de la investigación sobre lenguajes y herramientas de transformación aceptadas por la OMG, se determinó que existen estándares los cuales son aplicados por la industria de la computación. Por lo cual no fue necesario desarrollar una herramienta propia que implementara un lenguaje y realizara la transformación de modelos. Como la transformación que se necesitaba realizar era de modelo a texto se seleccionó el lenguaje y herramienta MOFScript. La herramienta utiliza como modelos de entrada modelos basados en MOF, por lo tanto se hizo la selección adecuada de elementos del modelo fuente y se creó el metamodelo necesario para la transformación. También, se crearon las reglas de transformación requeridas conforme al mapeo de los elementos MOS a elementos WSDL y BPEL. Se realizaron pruebas para verificar que las especificaciones WSDL se obtuvieron correctamente de los modelos fuente al aplicar las reglas de transformación. Estas pruebas contemplaron la creación de modelos MOS en el prototipo de modelado, la ejecución de las reglas de transformación sobre los modelos MOS así como la obtención de los documentos WSDL y BPEL, y el último paso fue la validación de que los documentos estuvieran bien formados usando NetBeans IDE 6.5. En el último paso de las pruebas se crearon servicios Web usando herramientas como NetBeans IDE 6.5 y JDeveloper 11g. Con cada uno de estos programas se crearon servicios Web a partir de los WSDL obtenidos de la transformación. Cada herramienta cuenta con un wizard que permite crear el código base del servicio Web a través de abrir las descripciones WSDL. Los documentos BPEL que se obtienen pueden ser visualizados en JDeveloper 11g, sin embargo, esta herramienta no cuenta con un wizard para crear la orquestación de los servicios a partir de abrir un documento BPEL. Por lo tanto estos documentos se consideran guías para la orquestación de los servicios Web. Finalmente, el prototipo fue usado para producir los modelos MOS, en el cual se puede visualizar el modelo gráficamente en forma de árbol o textualmente en formato XML. A través de una opción del prototipo se generan y guardan los modelos MOS que son usados por la herramienta MOFScript para llevar a cabo la transformación. 87

98 Conclusiones Aportaciones Una de las aportaciones principales de este trabajo es que la metodología incluye un enfoque de negocios donde se representan las funcionalidades de éste como servicios. Esto permite la obtención directa de las especificaciones WSDL. Es importante puntualizar que la aplicación de este enfoque de negocios junto con la arquitectura dirigida por modelos hacen de la metodología propuesta una fuente confiable en la generación de los documentos WSDL. Por lo tanto, las descripciones WSDL obtenidas reunen tanto los requerimientos del usuario como el uso de estándares aplicados en la industria de desarrollo de software. Otra aportación es el metamodelo del modelo organizacional orientado a servicios, el cual puede ser extendido para abarcar todas las etapas de modelado que son presentadas en el trabajo de [ESTR08]. El metamodelo creado, al estar basado en MOF puede ser usado por varias herramientas para su manipulación, característica que no se cumplía antes por ser un modelo de dominio específico. Trabajo futuro Para ampliar y crear descripciones WSDL más detalladas se necesita modificar el metamodelo MOS para considerar lógica de programación y así completar la generación de servicios Web. Una sugerencia es que en el modelo de protocolo se deben establecer tareas básicas que correspondan a operaciones básicas de programación (for, while, switch). Si se extiende o modifica el modelo específico de dominio se debe considerar que el metamodelo mos.ecore debe ser reestructurado y se deben extender las reglas de transformación. Además se puede producir una descripción más detallada de la utilización de los servicios Web que se generan. Es decir, generar documentación de cada uno de las especificaciones WSDL detallando la intención del servicio, operaciones, elementos de entrada y el resultado obtenido, así como del documento BPEL de la composición de servicios. Finalmente, se propone hacer un análisis para un cambio del prototipo a un ambiente de gráficos para una interacción más libre y contemplar todo el proceso de modelado del trabajo de tesis doctoral de [ESTR08]. 88

99 Anexo A Escenarios de los casos de uso En este anexo se presentan los escenarios completos de todos los casos de uso creados durante el análsis del prototipo de modelado. Los casos de uso son presentados en el capítulo 6 de esta tesis: CU_1 Modelar servicios de una organización, CU_2 Generar modelo MOS. Así como también los subcasos de uso: CU_1.1 Modelar servicio compuesto, CU_1.2 Modelar servicio básico, CU_1.3 Modelar procesos, CU_1.4 Modelar protocolo, CU_2.1 Identificar propiedades de los elementos MOS y CU_2.2 Guardar información del modelo. 89

100 Anexo A Escenarios de los casos de uso Tabla A.1: Escenario del caso de uso CU_1 Modelar servicios de una organización ID CU_1 Nombre Modelar servicios de una organización Creador Itzel Morales Ramírez Fecha de creación 11/05/09 Fecha de última 20/07/09 modificación Actores Usuario Descripción Permite al usuario modelar los servicios expuestos por una organización. Flujo básico 1. El usuario selecciona la opción de crear un modelo. 2. Se ingresa el nombre del modelo. 3. Se ingresa la descripción del modelo. 4. Se agregan los servicios compuestos, o 5. Se agregan los servicios básicos, o ambos. 6. Se agregan los procesos. 7. Se agregan las tareas. 8. Se agregan los recursos. 9. El modelo está completo. 10. Termina. Flujo alterno de éxito 1 (Modelo creado) Un modelo en uso o abrir un modelo creado previamente: 1. Puede realizar modificaciones al modelo. 2. Puede agregar: servicio compuesto, servicio básico, proceso, tarea y/o recurso. 3. Termina. Flujo alterno de éxito 2 (Modelo creado) Flujo alterno de fracaso 1 Flujo alterno de fracaso 2 Flujo alterno de fracaso 3 Flujo alterno de fracaso 4 Pre-condiciones Un modelo en uso o abrir un modelo creado previamente: 1. Puede realizar modificaciones al modelo. 2. Puede eliminar: servicio compuesto, servicio básico, proceso, tarea y/o recurso. 3. Termina. 1. El usuario está usando un modelo. 2. El usuario intenta agregar elementos en desorden (ej. agregar procesos a los servicios compuestos). 3. Se muestra un mensaje de error: Este elemento no puede ser agregado. 4. Termina. Un modelo previamente creado: 1. El usuario selecciona la opción de abrir, para buscar un modelo creado previamente. 2. La herramienta no puede abrir el modelo y manda un mensaje de error: No se puede abrir el modelo. 3. Termina. 1. El usuario está usando un modelo. 2. El usuario intenta eliminar un elemento que tiene subelementos. 3. La herramienta manda un mensaje para confirmar la eliminación: El elemento seleccionado tiene subelementos, si decide aceptar se eliminarán también. 1. El usuario está usando un modelo. 2. El usuario intenta eliminar un elemento sin subelementos. 3. La herramienta lo elimina. 4. Termina El modelo a crear debe tener servicios, procesos y tareas que puedan ser automatizados. 90

101 Anexo A Escenarios de los casos de uso Post-condiciones Subcasos de uso Suposiciones Obtención de un modelo orientado a servicios. CU_1.1 Modelar servicio compuesto. CU_1.2 Modelar servicio básico. CU_1.3 Modelar procesos. CU_1.4 Modelar protocolo La máquina del usuario debe tener instalado el prototipo. El usuario tiene conocimientos sobre como modelar servicios bajo el enfoque usado en esta tesis. 91

102 Anexo A Escenarios de los casos de uso Inicio Nuevo modelo Crear modelo Modelo creado Buscar modelo anterior Modelo abierto Modificar No modificar Error al abrir Ingresar nombre del modelo Agregar Eliminar Eliminar un elemento Error: "No se puede abrir el modelo" Se agregan elementos Se ingresa la descripción del modelo Tiene subelementos Se agregan los serv icios compuestos Si Válido Servicio compuesto No válido si Mensaje: "El elemento seleccionado tiene subelementos, si decide aceptar se eliminarán también." Se agregan los serv icios básicos Si Servicio básico Proceso Error: "Este elemento no puede ser agregado" Aceptar Se agregan los procesos Si Tarea no Elimina Cancelar Se agregan las tareas Si Recurso Se agregan los recursos Si Termina Figura A.1: Diagrama de actividad del caso de uso CU_1 92

103 Anexo A Escenarios de los casos de uso Tabla A.2: Escenario del caso de uso CU_1.1 Modelar servicio compuesto ID CU_1.1 Nombre Modelar servicio compuesto Creador Itzel Morales Ramírez Fecha de creación 11/05/09 Fecha de última 20/07/09 modificación Actores Usuario Descripción Permite al usuario agregar servicios compuestos al modelo. Flujo básico 1. El usuario selecciona el modelo creado. 2. Se agrega un servicio compuesto al modelo. 3. Se ingresa el nombre del servicio. 4. Se ingresa la descripción del servicio. 5. Se ingresa el orden de ejecución cero. 6. Se agregan los servicios básicos. 7. Se agregan los procesos. 8. Se agregan las tareas 9. Se agregan los recursos. 10. Termina. Flujo alterno de éxito 1 Un modelo que ya tiene servicio compuesto: (Modelo creado) 1. Se agrega un servicio compuesto dentro del servicio compuesto ya agregado. 2. Se ingresa el nombre del servicio. 3. Se ingresa la descripción del servicio. 4. Se ingresa el orden de ejecución cero. 5. Se agregan los servicios básicos. 6. Se agregan los procesos. 7. Se agregan las tareas. 8. Se agregan los recursos. 9. Termina. Flujo alterno de fracaso 1 Flujo alterno de fracaso 2 Flujo alterno Pre-condiciones Post-condiciones Al agregar un servicio compuesto: 1. El usuario no ingresa todas las propiedades de los servicios. 2. El usuario desea agregar otro elemento. 3. Se manda un mensaje de error: Debe ingresar todas las propiedades. 4. Termina. Un modelo que ya tiene servicio compuesto: 1. Se agrega un elemento que no es válido. 2. Se manda un mensaje de error: Este elemento no puede ser agregado. 3. Termina. Los servicios compuestos deben tener la característica de poder ser automatizados. Obtención de un modelo con servicios compuestos. Suposiciones La máquina del usuario debe tener instalado el prototipo. El usuario tiene conocimientos sobre como modelar servicios bajo el enfoque usado en esta tesis. 93

104 Anexo A Escenarios de los casos de uso Inicio Selección del modelo creado Se agregan elementos Agrega servicio compuesto Se agrega un servicio compuesto al modelo Se ingresa el nombre del servicio Si Válido Servicio compuesto No válido Error: "Este elemento no puede ser agregado" Se ingresa la descripción del serv icio Se ingresa el orden de ejecución cero No se ingresaron todas las propiedades Error: "Debe ingresar todas las propiedades" Ingresó todas las propiedades Agrega servicio básico Se agregan los servicios básicos Si Servicio básico Se agregan los procesos Se agregan las tareas Se agregan los recursos Termina Figura A.2: Diagrama de actividad del caso de uso CU_1.1 94

105 Anexo A Escenarios de los casos de uso Tabla A.3: Escenario del caso de uso CU_1.2 Modelar servicio básico ID CU_1.2 Nombre Modelar servicio básico Creador Itzel Morales Ramírez Fecha de creación 11/05/09 Fecha de última 20/07/09 modificación Actores Usuario Descripción Permite al usuario agregar servicios básicos al modelo. Flujo básico 1. El usuario selecciona el servicio compuesto correspondiente. 2. Se agrega un servicio básico al modelo. 3. Se ingresa el nombre del servicio. 4. Se ingresa la descripción del servicio. 5. Se ingresa el orden de ejecución. 6. Se agregan los procesos. 7. Se agregan las tareas 8. Se agregan los recursos. 9. Termina. Flujo alterno de éxito 1 (Modelo creado) Un modelo que ya tiene servicio básico: 1. Se agregan los procesos. 2. Se agregan las tareas. 3. Se agregan los recursos. 4. Termina. Flujo alterno de fracaso 1 Flujo alterno de fracaso 2 Pre-condiciones Post-condiciones Al agregar un proceso: 1. El usuario no ingresa todas las propiedades del servicio básico. 2. El usuario desea agregar otro elemento. 3. Se manda un mensaje de error: Debe ingresar todas las propiedades. 4. Termina. Un modelo que ya tiene servicio básico: 1. Se agrega un elemento que no es válido. 2. Se manda un mensaje de error: Este elemento no puede ser agregado. 3. Termina. Los servicios básicos deben tener la característica de poder ser automatizados. El modelo ya ha sido seleccionado. Obtención de un modelo con servicios compuestos y servicios básicos. Suposiciones La máquina del usuario debe tener instalado el prototipo. El usuario tiene conocimientos sobre como modelar servicios bajo el enfoque usado en esta tesis. 95

106 Anexo A Escenarios de los casos de uso Inicio Selección del serv icio compuesto Servicio básico existente Se agrega un servicio básico al modelo Se agregan elementos Se ingresa el nombre del servicio Válido No válido Error: "Este elemento no puede ser agregado" Se ingresa la descripción del servicio Se ingresa el orden de ejecución Error: "Debe ingresar todas las propiedades" No se ingresaron todas las propiedades Ingresó todas las propiedades Se agregan las procesos Si Proceso Se agregan las tareas Se agregan los recursos Termina Figura A.3: Diagrama de actividad del caso de uso CU_1.2 96

107 Anexo A Escenarios de los casos de uso Tabla A.4: Escenario del caso de uso CU_1.3 Modelar procesos ID CU_1.3 Nombre Modelar procesos Creador Itzel Morales Ramírez Fecha de creación 11/05/09 Fecha de última 20/07/09 modificación Actores Usuario Descripción Permite al usuario agregar procesos al modelo. Flujo básico 1. El usuario selecciona el servicio básico correspondiente. 2. Se agrega un proceso al modelo. 3. Se ingresa el nombre del proceso. 4. Se ingresa la descripción del proceso. 5. Se ingresa el orden de ejecución. 6. Se ingresa la propiedad transaccional NT o T. 7. Se agregan las tareas 8. Se agregan los recursos. 9. Termina. Flujo alterno de éxito 1 (Modelo creado) Un modelo que ya tiene proceso: 1. Se agregan las tareas. 2. Se agregan los recursos. 3. Termina. Flujo alterno de fracaso 1 Flujo alterno de fracaso 2 Pre-condiciones Post-condiciones Suposiciones Al agregar una tarea: 1. El usuario no ingresa todas las propiedades del proceso. 2. El usuario desea agregar otro elemento. 3. Se manda un mensaje de error: Debe ingresar todas las propiedades. 4. Termina. Un modelo que ya tiene proceso: 1. Se agrega un elemento que no es válido. 2. Se manda un mensaje de error: Este elemento no puede ser agregado. 3. Termina. Los procesos deben tener la característica de poder ser automatizados. Obtención de un modelo con servicios compuestos, servicios básicos y procesos. La máquina del usuario debe tener instalado el prototipo. El usuario tiene conocimientos sobre como modelar servicios bajo el enfoque usado en esta tesis. 97

108 Anexo A Escenarios de los casos de uso Inicio Selección del servicio básico Proceso existente Se agrega un proceso al modelo Se agregan elementos Se ingresa el nombre del proceso Se ingresa la descripción del proceso Válido No válido Error: "Este elemento no puede ser agregado" Se ingresa el orden de ejecución Se ingresa la propiedad transaccional "NT" o "T" Error: "Debe ingresar todas las propiedades" No ingresó todas las propiedades Ingresó todas las propiedades Se agregan las tareas Si Tarea Se agregan los recursos Termina Figura A.4: Diagrama de actividad del caso de uso CU_1.3 98

109 Anexo A Escenarios de los casos de uso Tabla A.5: Escenario del caso de uso CU_1.4 Modelar protocolo ID CU_1.4 Nombre Modelar protocolo Creador Itzel Morales Ramírez Fecha de creación 11/05/09 Fecha de última 20/07/09 modificación Actores Usuario Descripción Permite al usuario agregar tareas y recursos al modelo. Flujo básico 1. El usuario selecciona el proceso correspondiente. 2. Se agrega una tarea al modelo. 3. Se ingresa el nombre de la tarea. 4. Se ingresa la descripción de la tarea. 5. Se ingresa el orden de ejecución. 6. Se ingresa el tipo: float, int, void, string. 7. Se ingresa la propiedad transaccional NT o T. 8. Se selecciona el tipo de recurso y se agrega. 9. Se ingresa el nombre. 10. Se ingresa la descripción. 11. Termina. Flujo alterno de éxito 1 (Modelo creado) Un modelo que ya tiene tareas: 1. Se agregan los recursos. 2. Termina. Flujo alterno de fracaso 1 Flujo alterno de fracaso 2 Pre-condiciones Post-condiciones Suposiciones Al agregar un recurso: 1. El usuario no ingresa todas las propiedades de la tarea. 2. El usuario desea agregar otro elemento. 3. Se manda un mensaje de error: Debe ingresar todas las propiedades. 4. Termina. Un modelo que ya tiene tareas: 1. Se agrega un elemento que no es válido. 2. Se manda un mensaje de error: Este elemento no puede ser agregado. 3. Termina. Las tareas deben tener la característica de poder ser automatizadas. Obtención de un modelo con servicios compuestos, servicios básicos, procesos, tareas y recursos. La máquina del usuario debe tener instalado el prototipo. El usuario tiene conocimientos sobre como modelar servicios bajo el enfoque usado en esta tesis. 99

110 Anexo A Escenarios de los casos de uso Inicio Selección del proceso Tarea existente Se agrega una tarea al modelo Se agregan elementos Se ingresa el nombre de la tarea Se ingresa la descripcón de la tarea Se ingresa el orden de ejecución Se ingresa el tipo: float, int, v oid, string Válido No válido Error: "Este elemento no puede ser agregado" Se ingresa la propiedad transaccional "NT" o "T" Error: "Debe ingresar todas las propiedades" No ingresó todas las propiedades Ingresó todas las propiedades Se selecciona el tipo de recurso y se agrega Si Recurso Se ingresa el nombre del recurso Se ingresa la descripción del recurso Termina Figura A.5: Diagrama de actividad del caso de uso CU_

111 Anexo A Escenarios de los casos de uso Tabla A.6: Escenario del caso de uso CU_2 Generar modelo MOS ID CU_2 Nombre Generar modelo MOS Creador Itzel Morales Ramírez Fecha de creación 11/05/09 Fecha de última 20/07/09 modificación Actores Usuario Descripción Permite al usuario generar el modelo *.mos. Flujo básico 1. El usuario selecciona la opción de generar el modelo MOS. 2. Se verifica que el modelo esté completo. 3. Se identifican las propiedades de los elementos MOS. 4. Se mapean las propiedades a elementos XML. 5. Se guarda la información del modelo. 6. Termina. Flujo alterno de fracaso 1 1. El usuario selecciona la opción de generar el modelo MOS. 2. El modelo no está completo. 3. Se manda un mensaje de error: El modelo debe estar completo para poder generarse. 4. Termina. Flujo alterno de fracaso 2 Pre-condiciones Post-condiciones 1. El usuario selecciona la opción de generar el modelo MOS. 2. Se verifica que el modelo esté completo. 3. Se identifican las propiedades de los elementos MOS. 4. Las propiedades no son correctas. 5. Se manda un mensaje de error: Las propiedades no son correctas, verifique. 6. Termina. El modelo debe estar completo. El modelo a convertir está abierto. Obtención de un modelo *.mos. Subcasos de uso Suposiciones CU_2.1 Identificar propiedades de los elementos MOS. CU_2.2 Guardar información del modelo. La máquina del usuario debe tener instalado el prototipo. 101

112 Anexo A Escenarios de los casos de uso Inicio Selecciona la opción de generar el modelo MOS Se v erifica que el modelo esté completo Modelo completo Si No Error: "El modelo debe estar completo para poder generarse" Se identifican las propiedades de los elementos MOS Error: "Las propiedades no son correctas, v erifique" No Propiedades correctas Si Se mapean las propiedades a elementos XML Se guarda la información del modelo Termina Figura A.6: Diagrama de actividad del caso de uso CU_2 102

113 Anexo A Escenarios de los casos de uso Tabla A.7: Escenario del caso de uso CU_2.1 Identificar propiedades de los elementos MOS ID CU_2.1 Nombre Identificar propiedades de los elementos MOS Creador Itzel Morales Ramírez Fecha de creación 11/05/09 Fecha de última 20/07/09 modificación Actores Herramienta Descripción Verifica que las propiedades sean las correctas, que los datos ingresados sean del tipo de dato establecido. Flujo básico 1. Inicia la lectura de las propiedades de cada uno de los elementos 2. Verifica si lo escrito corresponde con el tipo de dato. 3. Se mapean las propiedades a elementos XML. 4. Se despliega en pantalla el modelo *.mos 5. Termina. Flujo alterno de fracaso 1 1. Inicia la lectura de las propiedades de cada uno de los elementos 2. Verifica si lo escrito corresponde con el tipo de dato. 3. Las propiedades no son correctas. 4. Se manda un mensaje de error: Las propiedades no son correctas, verifique. 5. Termina. Pre-condiciones Post-condiciones El modelo debe estar completo. El modelo a convertir está abierto. Obtención de un modelo *.mos en pantalla. Suposiciones La máquina del usuario debe tener instalado el prototipo. 103

114 Anexo A Escenarios de los casos de uso Inicio Inicia la lectura de las propiedades de cada uno de los elementos Verifica si lo escrito corresponde con el tipo de dato Propiedades correctas Si No Error: "Las propiedades no son correctas, v erifique" Se mapean las propiedades a elementos XML Se despliega en pantalla el modelo *.mos Termina Figura A.7: Diagrama de actividad del caso de uso CU_

115 Anexo A Escenarios de los casos de uso Tabla A.8: Escenario del caso de uso CU_2.2 Guardar información del modelo ID CU_2.2 Nombre Guardar información del modelo Creador Itzel Morales Ramírez Fecha de creación 11/05/09 Fecha de última 20/07/09 modificación Actores Usuario Descripción Se guarda el modelo MOS como un archivo de tipo *.mos Flujo básico 1. Se guarda el modelo como archivo. 2. El archivo toma el nombre del modelo. 3. Genera el archivo *.mos 4. Termina. Flujo alterno de fracaso 1 1. Se guarda el modelo como archivo. 2. No se puede guardar. 3. Se manda un mensaje de error: Error al guardar. 4. Termina. Pre-condiciones El modelo debe estar en pantalla. Post-condiciones Obtención de un archivo *.mos. Suposiciones La máquina del usuario debe tener instalado el prototipo. Inicio Se guarda el modelo como archiv o El archiv o toma el nombre del modelo Se guarda No Error: "Error al guardar" Si Genera el archivo *.mos Termina Figura A.8: Diagrama de actividad del caso de uso CU_

116 Anexo B Diagramas de secuencia En este anexo se presentan los diagramas de secuencia correspondientes a cada caso de uso. Cada diagrama de secuencia muestra la secuencia de pasos a seguir para realizar el modelado de cada uno de los elementos MOS. 106

117 Anexo B Diagramas de secuencia FrmPrincipal Archivo arbol cbelemento Control ElementoMOS Usuario abrirmodelo() abrir() abrir() reconstruirmodelo() setmodel() agregar() nuevo() getselecteditem() new(nombre, descripcion, ordene) :servicio compuesto agregarelemento() seleccionarservicio() nuevo() getselecteditem() new(nombre, descripcion, ordene) :servicio compuesto agregarelemento() Figura B.9: Diagrama de secuencia del caso de uso CU_1.1 FrmPrincipal arbol cbelemento Control ElementoMOS Usuario seleccionarservicio() agregar() nuevo() getselecteditem() new(nombre, descripcion, ordene) :servicio basico agregarelemento() Figura B.10: Diagrama de secuencia del caso de uso CU_

118 Anexo B Diagramas de secuencia FrmPrincipal arbol cbelemento Control ElementoMOS Usuario seleccionarservicio() agregar() nuevo() getselecteditem() new(nombre, descripcion, ordene, propiedadt) :proceso agregarelemento() Figura B.11: Diagrama de secuencia del caso de uso CU_1.3 FrmPrincipal arbol cbelemento Control ElementoMOS Usuario seleccionarproceso() agregar() nuevo() getselecteditem() new(nombre, descripcion, ordene, tipo, propiedadt) :tarea agregarelemento() agregar() nuevo() getselecteditem() new(nombre, descripcion, tipo) :recurso agregarelemento() Figura B.12: Diagrama de secuencia del caso de uso CU_

119 Anexo B Diagramas de secuencia Control Analizador Archivo Herramienta generarmos() comprobarcompletitud() valida() :boolean generarmosxml() :mosxml Figura B.13: Diagrama de secuencia del caso de uso CU_2.1 FrmPrincipal Control Archivo Usuario guardarinfo() guardarmos() guardar() :boolean JOptionPane() Figura B.14: Diagrama de secuencia del caso de uso CU_

120 Anexo C Descripción de los casos de prueba Prueba No.1 Elementos de la prueba Modelo orientado a servicios creado en el prototipo de modelado (figura c.15). Especificación de entrada Modelo con el servicio compuesto Tramitar licencia de manejo, el cual contiene al servicio básico Pago licencia y éste contiene los procesos: Encontrar costo y Registrar pago, los dos procesos son transaccionales por lo tanto cada uno de éstos permitirá crear un servicio Web a través de las reglas de transformación. 110

121 Anexo C Descripción de los casos de prueba Figura C.15: Creación del ModeloPrueba1 en el prototipo de modelado Especificación de salida a) Modelo con extensión *.mos (figura c.16) el cual permitirá la obtención de los documentos WSDL y BPEL. Figura C.16: ModeloPrueba1.mos obtenido en el prototipo 111

122 Anexo C Descripción de los casos de prueba b) Documentos WSDL: registrarpago.wsdl (figura c.17) y encontrarcosto.wsdl (figura c.18), visualizados en NetBeans IDE 6.5. Figura C.17: registrarpago.wsdl Figura C.18: encontrarcosto.wsdl c) Documento BPEL: pagolicencia.bpel que será el que represente al servicio básico Pago licencia, visualizado en JDeveloper 11g (figura c.19 y figura c.20). 112

123 Anexo C Descripción de los casos de prueba Figura C.19: pagolicencia.bpel 113

124 Anexo C Descripción de los casos de prueba Figura C.20: XML pagolicencia.bpel 114

125 Anexo C Descripción de los casos de prueba Prueba No.2 Elementos de la prueba Modelo orientado a servicios creado en el prototipo de modelado (figura c.21). Especificación de entrada Modelo con el servicio compuesto Tramitar licencia de manejo, el cual contiene al servicio básico Tramitar renovacion y éste contiene los procesos: Cotejar informacion, Renovar datos, Tomar foto y Entregar licencia. El proceso que es transaccional es Renovar datos por lo tanto éste permitirá crear un servicio Web a través de las reglas de transformación. Figura C.21: Creación del ModeloPrueba2 en el prototipo de modelado Especificación de salida a) Modelo con extensión *.mos (figura c.22) el cual permitirá la obtención de los documentos WSDL y BPEL. 115

126 Anexo C Descripción de los casos de prueba Figura C.22: ModeloPrueba2.mos obtenido en el prototipo b) Documento WSDL: renovardatos.wsdl (figura c.23), visualizado en NetBeans IDE 6.5. Figura C.23: renovardatos.wsdl 116

127 Anexo C Descripción de los casos de prueba c) Documento BPEL: tramitarrenovacion.bpel que será el que represente al servicio básico Tramitar renovacion, visualizado en JDeveloper 11g (figura c.24 y figura c.25). Figura C.24: tramitarrenovacion.bpel 117

128 Anexo C Descripción de los casos de prueba Figura C.25: XML tramitarrenovacion.bpel 118

129 Anexo C Descripción de los casos de prueba Prueba No.3 Elementos de la prueba Modelo orientado a servicios creado en el prototipo de modelado (figura c.26). Especificación de entrada Modelo con el servicio compuesto Comprar articulos, el cual contiene al servicio básico Verificar stock y éste contiene los procesos: Recibir solicitud, Checar inventario y Devolver existencia. El proceso que es transaccional es Checar inventario por lo tanto éste permitirá crear un servicio Web a través de las reglas de transformación. Figura C.26: Creación del ModeloPrueba3 en el prototipo de modelado Especificación de salida a) Modelo con extensión *.mos (figura c.27) el cual permitirá la obtención del documento WSDL. 119

130 Anexo C Descripción de los casos de prueba Figura C.27: ModeloPrueba3.mos obtenido en el prototipo b) Documento WSDL: checarinventario.wsdl (figura c.28), visualizado en NetBeans IDE 6.5. Figura C.28: checarinventario.wsdl 120

131 Anexo C Descripción de los casos de prueba Prueba No.4 Elementos de la prueba Modelo orientado a servicios creado en el prototipo de modelado (figura c.29). Especificación de entrada Modelo con el servicio compuesto Comprar articulos, el cual contiene al servicio básico Realizar pago y éste contiene los procesos: Registrar cliente, Registrar pago y Enviar almacen. Los tres procesos anteriores son transaccionales por lo tanto permitirán crear los servicios Web a través de las reglas de transformación. Figura C.29: Creación del ModeloPrueba4 en el prototipo de modelado Especificación de salida a) Modelo con extensión *.mos (figura c.30) el cual permitirá la obtención de los documentos WSDL y BPEL. 121

132 Anexo C Descripción de los casos de prueba Figura C.30: ModeloPrueba4.mos obtenido en el prototipo b) Documentos WSDL: registrarcliente.wsdl (figura c.31), registrarpago.wsdl (figura c.32) y enviaralmacen.wsdl (figura c.33), visualizados en NetBeans IDE 6.5. Figura C.31: registrarcliente.wsdl 122

133 Anexo C Descripción de los casos de prueba Figura C.32: registrarpago.wsdl Figura C.33: enviaralmacen.wsdl c) Documento BPEL: realizarpago.bpel que será el que represente al servicio básico Realizar pago, visualizado en JDeveloper 11g (figura c.34 y figura c.35). 123

134 Anexo C Descripción de los casos de prueba Figura C.34: realizarpago.bpel 124

135 Anexo C Descripción de los casos de prueba Figura C.35: XML realizarpago.bpel 125

136 Anexo C Descripción de los casos de prueba Prueba No.5 Elementos de la prueba Modelo orientado a servicios creado en el prototipo de modelado (figura c.36). Especificación de entrada Modelo con el servicio compuesto Comprar articulos, el cual contiene al servicio básico Preparar envio y éste contiene los procesos: Registrar direccion, Eliminar de inventario, Empaquetar y Guia de embarque. De los procesos anteriores el único que no es transaccional es Empaquetar por lo tanto los otros tres permitirán crear los servicios Web a través de las reglas de transformación. Figura C.36: Creación del ModeloPrueba5 en el prototipo de modelado Especificación de salida a) Modelo con extensión *.mos (figura c.37) el cual permitirá la obtención de los documentos WSDL y BPEL. 126

137 Anexo C Descripción de los casos de prueba Figura C.37: ModeloPrueba5.mos obtenido en el prototipo b) Documentos WSDL: registrardireccion.wsdl (figura c.38), eliminardeinventario.wsdl (figura c.39) y guiadeembarque.wsdl (figura c.40), visualizados en NetBeans IDE 6.5. Figura C.38: registrardireccion.wsdl 127

138 Anexo C Descripción de los casos de prueba Figura C.39: eliminardeinventario.wsdl Figura C.40: guiadeembarque.wsdl c) Documento BPEL: prepararenvio.bpel que será el que represente al servicio básico Preparar envio, visualizado en JDeveloper 11g (figura c.41 y figura c.42). 128