tabla de contenido · listado de figuras figura 1. marco orientado a objetos del dominio de la...

TABLA DE CONTENIDO

TABLA DE CONTENIDO i

Capítulo 1) INTRODUCCIÓN 1

Capítulo 2) ANTECEDENTES 5 2.1. Antecedentes Históricos y Trabajos Relacionados 5

2.1.1. Historia de las Tecnologías para Reuso 5 2.1.1.1. Programación por Procedimientos 6 2.1.1.2. Programación Modular 6 2.1.1.3. Programación por Tipos de Datos Abstractos 7 2.1.1.4. Programación Orientada a Objetos 7 2.1.1.5. Patrones de Diseño 8 2.1.1.6. Marcos Orientados a Objetos 8

2.1.2. Trabajos de Marcos Orientados a Objetos Relacionados 10 2.1.2.1. Framework Composition: Problems, Causes and Solutions 10 2.1.2.2. A “framework” for Object Oriented Framework Design 10 2.1.2.3. Identifying and Addressing Problems in Framework Reuse 11 2.1.2.4. Helping Object-Oriented Framework Use and Evaluation by Means of Historical Use Information 11 2.1.2.5. Análisis de Conceptos Formales (ACF) como Soporte para la Construcción de Frameworks de Dominio 11 2.1.2.6. Líneas de Productos, Componentes, Frameworks y Mecanos 12

2.1.3. Historia de los Sistemas Distribuidos 12 2.1.3.1. Programación Basada en Componentes (por sus siglas en inglés CBP) 12 2.1.3.2. COM (Component Object Model) y DCOM (Distributed Component Object Model) 14 2.1.3.2. CORBA (Common Object Request Broker Architecture) 15 2.1.3.3. RMI (Remote Method Invocation) 16 2.1.3.4. Arquitectura Orientada a Servicios y Servicios Web 17

2.1.4. Trabajos de Servicios Web Relacionados 21 2.1.4.1. Migrating Interactive Legacy Systems to Web Services 21 2.1.4.2. Migración de Sistemas de Información Legados a Servicios Web como Plataforma para lograr la Integración b2b 21 2.1.4.3. Generación Semi-automática de Servicios Web 21 2.1.4.4. Migrating COBOL Systems to the Web by using the MVC Design Pattern 22 2.1.4.5. Creating Web Services from Legacy Host Programs 22 2.1.4.5. Migration of Legacy Web Applications to Enterprise Java™ Environments – Net.Data® to JSP™ Transformation* 22 2.1.4.6. Supporting Migration to Services using Software Architecture Reconstruction 22

2.2. Justificación 24 2.3. Beneficios 25 2.4. Planteamiento del problema 25 2.5. Objetivo 26 2.6. Solución del Problema 26 2.7. Alcances y Límites 26

2.7.1. Alcances 26 2.7.2. Limitaciones 28

Capítulo 3) MARCO TEÓRICO 30

i

3.1. Marco Orientado a Objetos 30

3.2. Servicios Web 33 3.2.1. Ventajas de los Servicios Web 34 3.2.2. Estándares Asociados a los Servicios Web 35 3.2.3. Herramientas para Desarrollar Servicios Web en Java 35

3.2.3.1. WASP (Web Application and Service Platform) 35 3.2.3.2. Apache Axis 35 3.2.3.3. JWSDP(Java Web Service Developer Pack) 36 3.2.3.4. Ant 36 3.2.3.5. JAXP (Java API for XML Processing) 36 3.2.3.6. JAXR (Java API for XML Registries) 36 3.2.3.7. JAX-RPC (Java API for XML-based Remote Procedure Calls) 37 3.2.3.8. JAX-WS (Java API for XML-Based Web Services) 37

3.3. Integración de Aplicaciones 37 3.4. Serialización de Objetos en Java 38

Capítulo 4) ANÁLISIS DE ESCENARIOS 39 4.1. Casos de Uso 40 4.2. Definición de Escenarios 40

4.2.1. Escenarios de la alternativa número 3 41 4.2.1.1. Escenario 1. Relaciones de Herencia 41 4.2.1.2. Escenario 2. Relaciones de asociación y agregación 47 4.2.1.3. Escenario 3. Patrón de diseño Strategy 51 4.2.1.4. Patrón de diseño Composite 53

4.3. ¿Qué opción se apegaría más a los principios de una Arquitectura Orientada a Servicios? 55

Capítulo 5) PROCEDIMIENTO PARA LA OBTENCIÓN DE MSW’s A PARTIR DE MOO’s 56

5.1. Análisis del MOO 58 5.1.1. Relaciones de Herencia (extends) 58 5.1.2. Relaciones de Agregación 59

5.2. Separación del Marco 59 5.3. Generación de Servicios Web 59 5.4. Integración de Aplicaciones de Servicios Web 66

Capítulo 6) IMPLEMENTACIÓN DE PROTOTIPO 70 6.1. Análisis del Sistema 70 6.2. Diseño del Sistema 74 6.3. Análisis del Código Fuente 81 6.4. Herramienta MOO2MSW (Marcos Orientados a Objetos hacia Marcos de Servicios Web) 83

Capítulo 7) EVALUACIÓN 88 7.1. Convención de nombres 88 7.2. Plan de pruebas 89

7.2.1. Plan de prueba MOO2MSW04-01 89 7.2.2. Introducción 90 7.2.3. Artículos a probar 91

ii

7.2.4. Características a ser probadas 92 7.2.5. Características excluidas de las pruebas 93 7.2.6. Enfoque 93 7.2.7. Criterio pasa/ no pasa de casos de prueba 93 7.2.8. Criterios de suspensión y requerimientos de reanudación 94 7.2.9. Tareas de pruebas 94 7.2.10. Liberación de pruebas 95 7.2.11. Requisitos ambientales 95 7.2.12. Responsabilidades 96 7.2.13. Riesgos y contingencias 96

7.3 Especificación de casos de prueba 96 7.3.1 Especificación del caso de prueba número 1 96 7.3.2. Caso de prueba número 2 102 7.3.3. Caso de prueba número 3 103

7.4. Tabla de resultados 104

Capítulo 8) CONCLUSIONES Y TRABAJO FUTURO 106 8.1.Conclusiones 106

8.2. Problemas enfrentados 108 8.3. Trabajo Futuro 108

Anexo A) ANÁLISIS Y DISEÑO DEL SISTEMA 115 A1. Análisis del Sistema 115

A1.1. Definición de Escenarios 115 A2. Diseño del Sistema 134

A2.1. Diagramas de Actividad 134

Anexo B) DISEÑO DE PRUEBA Y CASOS DE PRUEBA 137 B1. Diseño de Prueba 137

B1.1. Diseño de Prueba para la Fase de Análisis del Procedimiento 137 B1.1.1. Especificación de diseño de prueba: MOO2MSW05-01 137 B1.1.2. Características a ser probadas 138 B1.1.3. Refinamientos del enfoque 138 B1.1.4. Identificación de pruebas 138 B1.1.5. Criterio pasa / no-pasa de evaluación de características 139

B1.2. Diseño de Prueba para la Fase de Separación del Procedimiento 139 B1.2.1. Especificación de diseño de prueba: MOO2MSW05-02 139 B1.2.2. Características probadas 139 B1.2.3. Refinamientos del enfoque 139 B1.2.4. Identificación de pruebas 140 B1.2.5. Criterio pasa / no-pasa de evaluación de características 140

B1.3. Diseño de Prueba para la Fase de Generación de Servicios Web del Procedimiento 140 B1.3.1. Especificación de diseño de prueba: MOO2MSW05-03 140 B1.3.2. Características probadas 140 B1.3.3. Refinamientos del enfoque 140 B1.3.4. Identificación de pruebas 141 B1.3.5. Criterio pasa / no-pasa de evaluación de características 141

B1.4. Diseño de Prueba para la Fase de Integración de Aplicaciones del Procedimiento 141 B1.4.1. Especificación de diseño de prueba: MOO2MSW05-04 141 B1.4.2. Características probadas 141 B1.4.3. Refinamientos del enfoque 142

iii

B1.4.4. Identificación de pruebas 142 B1.4.5. Criterio pasa / no-pasa de evaluación de características 142

B2. Especificación de Casos de Prueba 142 B2.1. Caso de prueba: MOO2MSW06-01 142

B2.1.1. Especificación de salida 142 B2.2. Caso de prueba: MOO2MSW06-02 158

B2.2.1. Especificación de salida 158 B2.3. Caso de prueba: MOO2MSW06-03 161

B2.3.1. Especificación de salida 161

iv

LISTADO DE FIGURAS Figura 1. Marco orientado a objetos del dominio de la estadística 25 Figura 2. Componentes que forman un servicio Web 34 Figura 3. Diagrama de casos de uso para la conversión de los componentes de un MOO a servicios Web 40 Figura 4. Herencia con datos y métodos privados 42 Figura 5. Servicios Web A y B 42 Figura 6. Herencia con métodos públicos y protegidos 43 Figura 7. Servicio Web C 43 Figura 8. Herencia de clases con métodos y atributos friendly 43 Figura 9. Servicio Web C 44 Figura 10. Clase A, ejemplo de llamada al constructor de la clase padre con un super 45 Figura 11. Clase Graphics, ejemplo de clases abstractas y métodos abstractos 45 Figura 12. Servicios Web Graphics y MiClase 45 Figura 13. Servicio Web MiClase 46 Figura 14. Clase GraphObj 46 Figura 15. Servicio Web GraphObject 46 Figura 16. Clase VideoClip, ejemplo de interfaz 47 Figura 17. Servicio Web MiClase 47 Figura 18. Clase A, ejemplo de relación de asociación 48 Figura 19. Integración de aplicaciones entre el servicio A y B 48 Figura 20. Servicios Web A y B 48 Figura 21. Clase A, ejemplo de relación de agregación débil 49 Figura 22. Relación de agregación débil 49 Figura 23. Clase A, ejemplo de relación de agregación fuerte 49 Figura 24. Relación de composición 49 Figura 25. Integración de aplicaciones entre A y B 50 Figura 26. Servicio Web C 50 Figura 27. Relación de composición a la clase base 50 Figura 28. Servicio Web C 51 Figura 29. Patrón de diseño Strategy 51 Figura 30. Ejemplo del patrón de diseño Strategy 51 Figura 31. Servicios Web Cuadrado y Círculo 52 Figura 32. Servicio Web Figuras Geométricas 52 Figura 33. Servicios Web Cuadrado y Círculo 53 Figura 34. Diagrama de clases de los cálculos de regresión y correlación 53 Figura 35. Clase cCorrPar2, ejemplo del patrón de diseño Composite 54 Figura 36. Servicio Web Regresión y Correlación 54 Figura 37. Servicios Web de Regresión y Correlación 55 Figura 38. Servicios Web de Regresión y Correlación 55 Figura 39. Procedimiento para la obtención de MSW a partir de MOO 57 Figura 40. Diagrama de clases del MOO Figuras Geométricas 60 Figura 41. Clase Figura del MOO Figuras Geométricas 60 Figura 42. Clase Circulo del MOO Figuras Geométricas 60 Figura 43. Clase FiguraGeometrica 61 Figura 44. Clase cSumatoria 62 Figura 45. Clase ServicioCalculoAritmetico 62 Figura 46. Fragmento del documento WSDL del servicio Web ServicioCalculoAritmetico 63 Figura 47. Clase Datos 63 Figura 48. Ejemplo de método Web 63 Figura 49. Declaración de un objeto serializable 64 Figura 50. Clase SerializarLista 64 Figura 51. Método para deserializar el objeto Lista 65 Figura 52. Ejemplo del documento WSDD del servicio Web HolaMundo 66

v

Figura 53. Ejemplo de la fase de integración de aplicaciones del procedimiento 67 Figura 54. Clase Calcular, ejemplo de la fase de integración de aplicaciones del procedimiento 68 Figura 55. Ejemplo de problema de múltiples llamadas entre servicios 69 Figura 56. Diagrama general de casos de uso 71 Figura 57. Diagrama del caso de uso Analizar código 72 Figura 58. Diagrama del caso de uso Separar el MOO 73 Figura 59. Diagrama del caso de uso Generar Servicio Web 74 Figura 60. Diagrama de clases general del sistema 75 Figura 61. Diagrama de clases del módulo de análisis 76 Figura 62. Diagrama de secuencias del módulo de análisis 77 Figura 63. Diagrama de clases del módulo de separación 78 Figura 64. Diagrama de secuencias del módulo de separación 79 Figura 65. Diagrama de clases del módulo de generación de servicios Web 80 Figura 66. Diagrama de secuencias del módulo de generación de servicios Web 81 Figura 67. Modelo relacional de la base de datos 83 Figura 68. Pantalla principal de la herramienta MOO2MSW 84 Figura 69. Diálogo para abrir múltiples archivos 85 Figura 70. Diálogo para mostrar los archivos a analizar 85 Figura 71. Sección “Fase 2. Separación” del sistema 86 Figura 72. Sección “Fase 3. Servicios Web” y “Fase 4. Agregación” del sistema 86 Figura 73. Convención de nombres 89 Figura 74. Diagrama del caso de prueba MOO2MSW06-01 98 Figura 75. Servicios Web esperados del caso de prueba MOO2MSW06-01 100 Figura 76. Servicios Web obtenidos del caso de prueba MOO2MSW06-01 101 Figura 77. Diagrama de clases Área _FigurasGeométricas 102 Figura 78. Servicios Web esperados del caso de prueba MOO2MSW06-02 103 Figura 79. Servicios Web obtenidos del caso de prueba MOO2MSW06-02 103 Figura 80. Diagrama de clases Área _FigurasGeométricas 103 Figura 81. Servicio Web esperados del caso de prueba MOO2MSW06-03 104 Figura 82. Servicio Web obtenido del caso de prueba MOO2MSW06-03 104 Figura 83. Diagrama de actividad del caso de uso CU-1 117 Figura 84. Diagrama de actividad del caso de uso CU-1.1 118 Figura 85. Diagrama de actividad del caso de uso CU-1.2 120 Figura 86. Diagrama de actividad del caso de uso separar el MOO 121 Figura 87. Diagrama de actividad del caso de uso separar las clases base 123 Figura 88. Diagrama de actividad del caso de uso separar clases derivadas 125 Figura 89. Diagrama de actividad del caso de uso separar interfaces 127 Figura 90. Diagrama de actividad del caso de uso CU-1 Generar servicios 129 Figura 91. Diagrama de actividad del caso de uso CU-1.1 Copiar servicios 130 Figura 92. Diagrama de actividad del caso de uso CU-1.2 Compilar archivos 131 Figura 93. Diagrama de actividad del caso de uso CU-1.4 Generar WSDD 132 Figura 94. Diagrama de actividad del caso de uso CU-1.5 Invocar WSDD 133 Figura 95. Diagrama de actividades del módulo de análisis del sistema 134 Figura 96. Diagrama de actividades del módulo de análisis del sistema 135 Figura 97. Diagrama de actividades del módulo de generación de servicios 136 Figura 98. Tabla de la base de datos bd, para el caso de prueba MOO2MSW06-01, que contiene información sobre la ubicación de las clases 143 Figura 99. Tabla de la base de datos bd, para el caso de prueba MOO2MSW06-0, que contiene información sobre las clases 143 Figura 100. Tabla de la base de datos bd, para el caso de prueba MOO2MSW06-01, que contiene información acerca de las relaciones de agregación 144 Figura 101. Carpeta ED 144 Figura 102. Carpeta Lista 144 Figura 103. Carpeta Elemento 144 Figura 104. Clase ServicioTendenciaCentral 145 Figura 105. Carpeta ServicioMetodoOrdenamiento 145

vi

Figura 106. Carpeta aCalculoAritmetico 145 Figura 107. Carpeta Interface 145 Figura 108. Carpeta clases del servidor axis 146 Figura 109. Directorio axi 146 Figura 110. Despliegue del servicio Web ED 147 Figura 111. Jerarquía de clases para Cálculos aritméticos 147 Figura 112. Relaciones de herencia presentes en el caso de prueba MOO2MSW06-01 147 Figura 113. Clase ServicioCalculoAritmetico 148 Figura 114. Despliegue del servicio Web ServicioCalculoAritmetico 149 Figura 115. Clase Cliente 149 Figura 116. Resultado de ejecutar la clase Cliente 150 Figura 117. Jerarquía de clases para Cálculos de ordenamiento 150 Figura 118. Ejemplo de llamadas recurrentes en un cliente hacia los servicios Elemento y ED 151 Figura 119. Servicios Web de métodos de ordenamiento 151 Figura 120. Jerarquía de clases para Cálculos de regresión 152 Figura 121. Servicios Web de cálculos de regresión 153 Figura 122. Jerarquía de clases para Cálculos de tendencia central 154 Figura 123. Servicios Web de los cálculos de tendencia central 154 Figura 124. Jerarquía de clases para Cálculos de dispersión 155 Figura 125. Servicios Web de cálculos de dispersión 155 Figura 126. Jerarquía de clases para ServicioMetodoOrdenamiento y ServicioTendenciaCentral 156 Figura 127. Servicio Web MetodoOrdenamiento 156 Figura 128. Jerarquía de clases para las clases Lista y Elemento 157 Figura 129. Servicios Web Lista y Elemento 157 Figura 130. Tabla de la base de datos bd del caso de prueba MOO2MSW06-02, que guarda información acerca de la ubicación de las clases 158 Figura 131. Tabla de la base de datos bd del caso de prueba MOO2MSW06-02, que guarda información sobre las clases 158 Figura 132. Tabla de la base de datos bd para el caso de prueba MOO2MSW06-02, que guarda información sobre las relaciones de agregación 159 Figura 133. Carpeta interface para el caso de prueba MOO2MSW06-02 159 Figura 134. Carpeta clases des servidor axis para el caso de prueba MOO2MSW06-02 160 Figura 135. Directorio axis para el caso de prueba MOO2MWS06-02 160 Figura 136. Ejemplo de un el documento WSDD del servicio Web cCirculo 161 Figura 137. Servicios Web de figuras geométricas 161 Figura 138. Relaciones de herencias presentes en el caso de prueba MOO2MSW06-03 162 Figura 139. Clase ServicioFigurasGeometricas 162 Figura 140. Directorio axis para el caso de prueba MOO2MSW06-03 163 Figura 141. Servicio Web ServicioFigurasGeometricas 163

vii

LISTADO DE TABLAS Tabla 1. Composición de Marcos de aplicaciones problemas y causas 10 Tabla 2. Características de los modelos distribuidos 20 Tabla 3. Ventajas y desventajas de los modelos distribuidos 20 Tabla 4. Dependencias identificadas en las relaciones de herencia 58 Tabla 5. Relaciones de herencia 59 Tabla 6. Artículos a probar 91 Tabla 7. Características a ser probadas 92 Tabla 8. Tareas de pruebas 94 Tabla 9. Tabla de resultados 105 Tabla 10. Identificación de pruebas MOO2MSW05-01 138 Tabla 11. Identificación de pruebas MOO2MSW05-02 140 Tabla 12. Identificación de prueba MOO2MSW05-03 141 Tabla 13. Identificación de pruebas MOO2MSW05-04 142

viii

GLOSARIO DE TÉRMINOS AGREGACIÓN Indica que una o más clases (clases componentes)

forman parte de otra clase (clase compuesta).

AXIS Implementación OpenSource de SOAP (Simple Object Access Protocol) que proporciona un entorno de ejecución para servicios Web implementados en Java, el cuál incluye un servlet que se integra con motores de servlets como Tomcat.

CLASE Unidad básica que encapsula toda la información de un Objeto.

COMPONENTE Una unidad de composición de software, que puede ser desarrollado, adquirido y utilizado independientemente, y que define las interfaces por medio de las cuáles puede ser ensamblado con otros componentes para proveer y usar servicios.

DESERIALIZAR La deserialización de un objeto consiste en reconstruir el estado original de un objeto a partir de una secuencia de bytes.

HERENCIA Es la propiedad que permite que nuevas clases puedan compartir la estructura y el comportamiento de clases existentes.

INTEGRACIÓN DE APLICACIONES

Servicios compuestos de varios servicios más simples.

INTERFACES Las interfaces Java son expresiones puras de diseño. Se trata de auténticas conceptualizaciones no implementadas que sirven de guía para definir una determinada clase y lo que debe hacer, pero sin desarrollar un mecanismo de solución.

JAVACC Es una herramienta generadora de analizadores léxicos y sintácticos escrita en el lenguaje de programación Java y a su vez produce código en Java.

MARCO DE SERVICIOS WEB

Conjunto de servicios Web pertenecientes a un mismo dominio de aplicaciones.

ix

MOO1 Marco Orientado a Objetos – Es un conjunto de clases en colaboración que abarca un diseño abstracto para dar soluciones a una familia de problemas relacionados.

OBJETO Instancia de una clase.

PATRÓN DE DISEÑO Es una unidad de información que captura la estructura esencial y la comprensión de una familia de soluciones exitosas probadas para un problema recurrente que ocurre dentro de cierto contexto y sistema de fuerzas.

PROCEDIMIENTO Serie de pasos consecutivos y claramente definidos que permiten trabajar correctamente.

REUSABILIDAD Es la habilidad que los productos de software tienen para su reuso, de manera total o en parte, en nuevas aplicaciones. El reuso es cualquier procedimiento que produce o ayuda a producir un nuevo componente de software a partir de un componente ya existente sin modificar a este último.

SERIALIZACIÓN La serialización de un objeto consiste en obtener una secuencia de bytes que represente el estado de dicho objeto.

SERVICIO WEB Aplicación que puede ser descrita, publicada, localizada, e invocada a través de una red.

SOA2 Arquitectura Orientada a Servicios - Es un estilo de arquitectura de software que promueve el desacoplamiento entre componentes de forma que se puedan reutilizar.

TOMCAT Es un motor de servlets de código abierto escrito en lenguaje java. Es una implementación desarrollada por la fundación Apache.

1 En esta tesis el término MOO se utiliza para hacer referencia al término en inglés “Framework”, el cual equivale a los términos en español “Marco”, “Marco Orientado a Objetos” y “Marco de Aplicaciones Orientado a Objetos". 2 En esta tesis el término SOA se utiliza para hacer referencia al término en inglés “Service Oriented Architecture”, el cual equivale al término en español “Arquitectura Orientada a Servicios".

x

UDDI Universal Description, Discovery, and Integration – registro basado en XML para la publicación de servicios Web.

WSDL Web Services Description Language - Lenguaje basado en XML para describir servicios Web.

XML Lenguaje de Etiquetado Extensible muy simple, pero estricto que juega un papel fundamental en el intercambio de una gran variedad de datos. Es un lenguaje muy similar al HTML pero su función principal es describir datos y no mostrarlos como es el caso de HTML. XML es un formato que permite la lectura de datos a través de diferentes aplicaciones.

xi

Capítulo 1. Introducción

Capítulo 1) INTRODUCCIÓN

Con el paso del tiempo, las empresas han desarrollado una gran cantidad de código para diferentes aplicaciones y dominios de sistemas, formando lo que hoy se conoce como marcos orientados a objetos (que en lo sucesivo serán denominados MOO’s).

Un MOO es un conjunto semi-completo de clases en colaboración, que incorpora un

diseño genérico el cual puede ser adaptado a una variedad de problemas específicos para producir nuevas aplicaciones hechas a la medida [1].

Los MOO’s son sistemas de información desarrollados para un dominio en específico,

como por ejemplo: el de la estadística, de la inteligencia artificial, del sector eléctrico, farmacéutico, entre otros. Entre más maduro sea el marco más completo es el dominio al que representa.

1


Los MOO’s presentan una serie de desventajas debido a que son desarrollados para su extensión pero no para su composición. Cuando se requiere que dos marcos colaboren entre sí, salen a relucir problemas como la dependencia de plataforma y de lenguaje, inhabilitando la posibilidad de su composición.

La forma en que colaboran los componentes que integran los marcos para su extensión

es por medio de relaciones de herencia y relaciones de agregación, estas últimas pueden ser de tipo fuerte o débil. Estas relaciones permiten que un mayor número de componentes sean incorporados al marco original enriqueciéndolo para alcanzar un mayor grado de madurez y de esta forma, poder adecuarlo para resolver nuevas aplicaciones de dominio con poco esfuerzo.

La construcción de MOO’s maduros no es tarea fácil y requiere de un gran esfuerzo

por parte de los desarrolladores, pero todo este esfuerzo se ve recompensado una vez que se obtienen beneficios importantes como el reuso tanto del código como del diseño y la reducción de costo y esfuerzo para el desarrollo de nuevas aplicaciones. Logrando de esta forma una de las metas principales de los ingenieros de software que buscan el reuso de código mediante la construcción de sistemas basados en la integración de componentes, lo que con otros paradigmas de programación sólo se podría realizar a nivel de librerías de funciones, lo cual sólo fomenta el reuso del código pero no del diseño.

Una tendencia actual en la ingeniería de software es extender la base de usuarios o

clientes de los componentes de reuso, para que estos no sólo sean usados de forma propietaria sino que toda la experiencia que proporcionan sea aprovechada por un mayor número de clientes, independientemente de la plataforma de desarrollo entre la entidad que solicita el servicio y el proveedor del mismo.

Los servicios Web son sistemas de información distribuidos que se describen, publican, localizan e invocan por los desarrolladores de software que implementan técnicas de reuso. Las empresas desarrolladoras de software están enfocadas a aprovechar los beneficios ofrecidos por las tecnologías Web migrando las aplicaciones legadas y centralizadas hacia Arquitecturas Orientadas a Servicios (por sus siglas en inglés SOA). El uso de los servicios Web esta tomando gran auge y cada día se incrementa más el número de servicios disponibles en el sistema de Especificación Universal de Descripción, Localización e Integración (por sus siglas en inglés UDDI). El hecho de que estos servicios estuvieran organizados por dominios en la UDDI, como lo es en un MOO, facilitaría su búsqueda, según la propuesta desarrollada en el departamento de ingeniería de software del CENIDET, en la que se especifican las ventajas que proporciona el sistema de búsqueda estructurado de servicios Web por dominios. Es posible que la tecnología de software actual permita poner en Internet los MOO’s como recursos de la Web a disposición de los desarrolladores de aplicaciones y del comercio electrónico, proporcionando los mismos beneficios que los marcos orientados a objetos de escritorio, pero ahora de forma distribuida y a disposición de un mayor número de aplicaciones.

2

Capítulo 1. Introducción Sin embargo si se convierte un marco con su funcionalidad completa en un servicio Web, los solicitantes tienen que invocar el servicio completo aunque sólo requieran de una parte específica del marco. Ya existen arquitecturas, metodologías y procedimientos que abordan la idea de migrar sistemas de información legados y aplicaciones Web hacia servicios Web. Todos proponen diferentes técnicas para cumplir su meta. Algunos trabajan sólo con lenguaje COBOL y logran la migración refactorizando el sistema con el patrón de diseño MVC (Modelo, Vista, Controlador). Otros aplican diferentes herramientas para identificar componentes reusables y algunos otros logran que las funcionalidades interactivas de los sistemas legados puedan ser accesibles también como servicios Web, pero ninguno aborda el problema de migrar MOO’s hacia servicios Web. Debido a las ventajas que proporciona el proceso de migración, en esta tesis se desarrolló un procedimiento integrado por 4 fases, que permite obtener componentes reusables como servicios Web a partir de MOO’s. Con este procedimiento se generan diferentes servicios de un mismo dominio y se hacen disponibles para que un usuario solicite únicamente las partes del marco requeridas, sin necesidad de entender y utilizar el marco en su totalidad. Para dar soporte al procedimiento se desarrolló la herramienta MOO2MSW. Organización del documento de tesis: A continuación se da un panorama de la organización del documento:

• En el capítulo 2 se presentan los antedecentes históricos, los trabajos relacionados, la justificación y los beneficios que dan soporte al desarrollo de la tesis. Además se describe la problemática tratada, el objetivo planteado, la solución dada al problema y los alcances y límites establecidos.

• En el capítulo 3 se describen los MOO’s, los servicios Web y el proceso de serialización de los servicios Web como fundamentos teóricos en el desarrollo del trabajo de tesis.

• En el capítulo 4 se presenta un análisis de los escenarios encontrados en el proceso de separación de los componentes que integran a un MOO para su posterior conversión a servicios Web.

• A partir de los escenarios analizados en el capítulo 4, en el capítulo 5 se describe el procedimiento a seguir para cumplir con el objetivo de migrar MOO’s a MSW’s.

• En el capítulo 6 se describe el análisis, diseño y funcionamiento de la herramienta MOO2MSW, desarrollada para dar soporte al procedimiento planteado en el capítulo 5.

• En el capítulo 7 se describe la evaluación experimental para probar la funcionalidad del procedimiento presentado en el capítulo 5.

• En el capítulo 8 se presentan las conclusiones de la tesis, así como posibles trabajos futuros.

3


• El Anexo A es una extensión del capítulo 6, y se presenta una descripción más detallada del análisis y diseño de la herramienta MOO2MSW.

• El Anexo B es una extensión del capítulo 7. Se presenta una descripción detallada del diseño y los casos de prueba a los que se sometió el procedimiento para probar su funcionalidad.

4

Capítulo 2. Antecedentes

Capítulo 2) ANTECEDENTES

En este capítulo se describe el estudio del estado del arte, que consta de los antecedentes históricos del proyecto de tesis y los trabajos relacionados. Además, se plantea el problema de reuso de los MOO’s como servicios Web; se describe la justificación; los objetivos de la tesis, así como también los alcances y límites establecidos.

2.1. Antecedentes Históricos y Trabajos Relacionados 2.1.1. Historia de las Tecnologías para Reuso Desde los inicios de la Ingeniería de Software (1968) uno de los principales objetivos perseguidos ha sido el reuso. Es por ello que a lo largo del tiempo se han desarrollado diferentes técnicas con este fin.

5

Capítulo 2. Antecedentes El término reuso fue originalmente postulado por M.D. McIloroy en la conferencia de la NATO de 1968 sobre Ingeniería de Software [2]. Desde entonces el reuso del software ha sido y sigue siendo uno de los principales temas de investigación en el campo de la Ingeniería de Software, citándose a menudo como una de las técnicas para incrementar la productividad de los desarrolladores de software [2]. El propósito del reuso es mejorar la eficiencia, la productividad y la calidad del desarrollo de software. El reuso puede definirse como “cualquier procedimiento que produce o ayuda a producir un sistema mediante el nuevo uso de algún elemento procedente de un esfuerzo de desarrollo anterior” [3]. Actualmente existen diferentes modelos de programación que de alguna manera han contribuido al reuso de software. Por ejemplo: el modelo de programación por procedimientos; el de programación modular; el de tipos de datos abstractos; y el orientado a objetos. 2.1.1.1. Programación por Procedimientos La programación por procedimientos surgió a inicios de la década de los 70s bajo el concepto de construir programas a partir de composición de funciones o procedimientos [1]. Las variables permitidas en este modelo son de tipo global, las cuales son compartidas por todas las funciones del programa; y de tipo local, en la que se controla el alcance y el tiempo de vida de las variables. La idea de reuso empleada en este modelo es la de permitir a los programadores ejecutar segmentos de código más de una vez sin tener que repetirlo en cada localidad física donde sea requerido. A esta aportación se le conoce como biblioteca de funciones y fue el primer acercamiento que se tuvo sobre el término reuso. A pesar de la gran aportación hecha por este modelo, su uso presenta ciertas desventajas. Por ejemplo el hecho que muchas funciones puedan acceder a muchos datos sin contar con el control de este tipo de accesos. Los programas generados son de una sola pieza y por ser diseñados para resolver problemas particulares, son difíciles de reusar aun en problemas del mismo dominio. Estos programas cuentan con una gran cantidad de líneas de código y un alto grado de acoplamiento entre sus funciones y procedimientos. Todos estos factores originan complejidad, dificultad de entendimiento y comprensión del código, así como también un bajo grado de cohesión entre datos y funciones. 2.1.1.2. Programación Modular Con el propósito de solucionar los problemas de mantenimiento y reuso presentados en el modelo de programación procedural, surgió la idea de separar el código de un programa en partes que pudieran operar de forma independiente y de esta forma reducir el grado de acoplamiento entre funciones, aumentar la cohesión y evitar el uso indiscriminado de variables globales por medio del ocultamiento de datos, es así como surge un nuevo modelo de programación conocido como programación modular.

6

Capítulo 2. Antecedentes En la programación modular, se organizan los programas por módulos que empaquetan las estructuras de datos con los procedimientos y funciones relacionados. Las estructuras de datos son locales a cada módulo, de esta forma los únicos que pueden acceder a las funciones son los miembros del módulo. Con este enfoque se logra reducir el costo de mantenimiento, debido a que las modificaciones en un módulo sólo causan repercusiones en algunos cuantos módulos y no en todo el programa. A su vez, se aumenta la probabilidad de reuso gracias a que se tiene cierta independencia entre los módulos. También se disminuye la complejidad y se puede aumentar la funcionalidad requerida en otras aplicaciones por medio de la integración entre módulos. 2.1.1.3. Programación por Tipos de Datos Abstractos La aportación hecha por la programación modular es muy considerable, sin embargo para aspectos de reuso es importante contar con mecanismos de abstracción de datos que permitan la creación de instancias reusables generadas por el usuario. Por esta razón surge la programación por tipos de datos abstractos. Un Tipo de Dato Abstracto (por sus siglas en inglés ADT) es un tipo de dato definido por el programador que se puede manipular de forma similar a los tipos de datos definidos por el sistema [4]. Con la obtención del modelo de ADT, surge la idea de que se puede lograr un mayor reuso si los componentes de un programa pueden ser adaptados a nuevos usos sin tener que modificar su forma actual. Esta idea da origen a una de las aportaciones más grandes al problema de reuso de software, la programación orientada a objetos. 2.1.1.4. Programación Orientada a Objetos La programación orientada a objetos es un método de implementación en el que los programas se organizan como colecciones colaborativas de objetos, cada uno representa una instancia de alguna clase, y las clases son miembros de una jerarquía, unidas mediante relaciones de herencia [1]. Los elementos básicos de este modelo son: la clase, la cual es una plantilla que permite la creación de objetos; los objetos, unidad en la que se encapsulan los atributos que determinan el estado y las funciones que determinan el comportamiento; los métodos, son la forma en la que un objeto responde a un mensaje y los mensajes, son solicitudes para el desarrollo de operaciones que generan un resultado. El modelo orientado a objetos permite la creación de programas por extensiones, en la que a mayor jerarquía corresponde a un nivel más abstracto y a menor jerarquía un nivel más específico. Las aplicaciones pueden ser reusadas extendiendo su funcionalidad en clases específicas, por medio de los mecanismos de herencia y composición de objetos.

7

Capítulo 2. Antecedentes Con el paso de los años se han observado problemas que surgen con cierta frecuencia, por lo que se han desarrollado diferentes formas para solucionarlos. De las soluciones propuestas se toma la que se considera que es la mejor y se sigue utilizando continuamente. A este proceso se le conoce como paradigma y es justo lo que ocurre con la programación orientada a objetos. 2.1.1.5. Patrones de Diseño Los patrones de diseño aparecen tras la tesis de E. Gamma [5] publicados en un libro que recoge no sólo su definición, sino todo un catálogo de patrones de diseño aplicables a la programación básica orientada a objetos, y que cubren la mayor parte de los pequeños problemas recurrentes que se plantean en el desarrollo de cualquier programa. El trabajo presentado por Gamma ha sido extendido por diferentes autores, por lo que actualmente existen catálogos con una gran cantidad de patrones, dirigidos a la solución de problemas diversos. Un patrón de diseño es una solución a un problema que se usa repetidamente en contextos similares con algunas variantes en la implementación [6]. Los patrones de diseño presentan algunos problemas, por ejemplo la propuesta de diseño implica que los programas deben ser desarrollados con patrones de diseños estándares, sin embargo esto no siempre es posible ya que cada dominio tiene necesidades específicas que deben ser tratadas de forma particular. Además la cantidad de patrones existentes es tan grande que en ocasiones resulta complicado su manejo, por lo que se recomienda basarse en un catálogo específico. Otro inconveniente es que no se encuentra definida la composición entre patrones de diseños por lo que se hace más difícil su uso. 2.1.1.6. Marcos Orientados a Objetos Una forma de reuso importante en la programación orientada a objetos son los Marcos Orientados a Objetos (MOO) los cuales se apoyan en los patrones de diseño para lograr un reuso no sólo a nivel de código si no también a nivel de diseño. Un MOO captura las decisiones de diseño comunes a un tipo de aplicaciones, estableciendo un modelo común a todas ellas, asignando responsabilidades y estableciendo colaboraciones entre las clases que forman el modelo. Este modelo común contiene puntos de variabilidad, conocidos como puntos calientes [7]. El concepto de MOO surge a mitad de la década de los 80s, los primeros ejemplos de MOO se encuentran en el entorno SmallTalk con la aplicación del marco MVC (Modelo Vista Controlador) y en el Apple Computer [8]. Los MOO’s se hicieron más populares cuando estuvieron disponibles algunos marcos para la construcción de interfaces gráficas de usuario, como por ejemplo Interviews o ET++ [8].

8

Capítulo 2. Antecedentes En 1992 surge el proyecto Taligent, el cual pretendía desarrollar un sistema operativo orientado a objetos basado en el concepto de marcos. La compañía desarrolló, bajo el nombre de CommonPoint, un conjunto de herramientas para el desarrollo rápido de aplicaciones, que consistían en más de 100 Marcos Orientados a Objetos. Con la aproximación de Taligent surge un nuevo enfoque, cambiando la idea de marcos monolíticos, a varios marcos de grano fino integrados [8]. Los patrones de diseño han sido el método más utilizado y recomendado para describir la lógica de diseño del propio marco. Existen diferentes clasificaciones de los marcos, pero las más utilizadas son dos: los marcos de aplicaciones y los marcos de dominios. Marcos de Aplicaciones: Encapsula una capa de funcionalidad horizontal que puede ser aplicada en la construcción de una gran variedad de programas. Además de los marcos que implementan las interfaces gráficas de usuario, que representan su paradigma, podemos clasificar en esta categoría los dedicados al establecimiento de comunicaciones o procesamiento de documentos XML entre otros [7]. Marcos de Dominio: Implementa una capa de funcionalidad vertical, correspondiente a un dominio de aplicación o una línea de producto. Estos son los más numerosos, y su evolución es también la más rápida pues deben de adaptarse a las áreas de negocio para las que están diseñados [7]. A su vez los marcos de dominios se pueden clasificar en tres categorías: Marcos de caja blanca: Su instanciación se realiza mediante técnicas de herencia, y por ello requiere de conocimientos sobre la implementación del marco por parte del desarrollador [7]. Marcos de caja negra: Se refiere a los puntos calientes y marcos en los que la instanciación se realiza mediante composición e instanciación de parámetros genéricos. Su uso es mucho más simple porque sólo requiere seleccionar de entre un conjunto de opciones predefinidas. Sin embargo, y por los mismos motivos, su construcción resulta mucho más difícil. [7] Marcos de caja gris: Es una mezcla de los dos tipos anteriores, que busca evitar sus desventajas. Permiten la extensión mediante la herencia y la ligadura dinámica, y además la propiedad de ocultar información innecesaria a los usuarios del marco [8]. El nivel de reuso alcanzado por los MOO’s representó un gran logro por parte de los ingenieros de software. Aún así, se encontraron algunos inconvenientes que pueden ser considerados una limitante en el proceso de reuso. Uno de ellos es el grado de acoplamiento que presentan, lo que ocasiona que las clases no pueden sacarse de su contexto, y el marco deba ser reusado como un solo componente. Por otra parte la dependencia de lenguaje y

9

Capítulo 2. Antecedentes plataforma impiden que los marcos puedan componerse para lograr una funcionalidad más completa y adaptable a las necesidades específicas de cada empresa. Estas desventajas son precisamente las que se buscan atacar en el presente trabajo de tesis. Para ello se propone llevar los MOO’s a Marcos de servicios Web (MSW), logrando de esta forma disminuir el grado de acoplamiento, separando el marco orientado objetos en una serie de componentes reusables de grano más fino que permitan utilizar sólo las partes requeridas y no el marco en su totalidad. Otro punto importante es que se disminuirá el problema de dependencia de lenguaje y plataforma, debido a que una de las características principales de los servicios Web es que son independientes del lenguaje de desarrollo y pueden ser utilizados bajo cualquier plataforma. 2.1.2. Trabajos de Marcos Orientados a Objetos Relacionados Con el objetivo de conocer más acerca del diseño, funcionamiento y del estado del arte en lo referente a marcos orientados a objeto se analizaron los siguientes trabajos (los títulos se dan en el idioma en que fueron publicados). 2.1.2.1. Framework Composition: Problems, Causes and Solutions En el trabajo descrito en la referencia [9] se presentan algunos problemas que pueden surgir en la etapa de desarrollo de la composición de marcos orientados a objetos, sus causas, las posibles soluciones y las limitantes de dichas soluciones, como se muestra en la siguiente tabla:

Tabla 1. Composición de Marcos de aplicaciones problemas y causas.

Composición del framework

de control

Composición con

componente de herencia

Hueco del Framework

Superposición de entidades

Composición de entidad funcional

Comportamiento cohesivo

Factor de Complicación Causa principal - Factor de

Complicación Factor de

Complicación Cobertura de

dominio - - Causa principal Causa principal -

Intención de Diseño causa principal Factor de

Complicación - Factor de Complicación Causa principal

Ningún acceso al código original.

Factor de complicación

Factor de Complicación




2.1.2.2. A “framework” for Object Oriented Framework Design En el trabajo descrito en la referencia [10] se describe un modelo flexible basado en componentes para el diseño de los marcos de aplicaciones. Acentúa una interfaz común para que nuevos componentes sean incorporados en diferentes etapas del ciclo de vida. Se presenta un análisis sobre las características de los marcos de aplicaciones, así como del rol y las interacciones de sus desarrolladores y usuarios. El framework desarrollado para el diseño de marcos depende de una secuencia lógica, que comienza en los requerimientos de usuario, después pasa a los requerimientos de los desarrolladores de aplicaciones, posteriormente a los requerimientos de los desarrolladores de

10

Capítulo 2. Antecedentes componentes y finalmente se fija la carga en el creador del marco de aplicaciones. En cada caso el desarrollador identifica un componente de interfaz único apropiado para la aplicación. 2.1.2.3. Identifying and Addressing Problems in Framework Reuse En el trabajo descrito en la referencia [11] se presenta un análisis de los problemas que son comúnmente encontrados en el proceso de reuso de un MOO. Los problemas contemplados son: mapeo, entendimiento del marco, el entendimiento de interacción y el entendimiento de la arquitectura del marco. Como solución a estos problemas se proponen dos formas de documentación: lenguajes de patrones y documentación de la microarquitectura. Según las pruebas realizadas con diferentes grupos de personas tanto con experiencia, como sin experiencia, se concluyó que los lenguajes de patrones sí proporcionan apoyo para el entendimiento del marco, sobre todo para aquellas personas que no tienen experiencia gracias a que introducen conceptos clave del marco y proporcionan ejemplos de su uso. Por el contrario la documentación de la microarquitectura no generó el efecto deseado en el entendimiento de la interacción. El motivo fue la complejidad para entender dicha interacción y el tiempo consumido. 2.1.2.4. Helping Object-Oriented Framework Use and Evaluation by Means of Historical Use Information El esfuerzo requerido para aprender a utilizar un marco orientado a objetos se puede reducir si se cuenta con información referente al cómo se utiliza el marco comúnmente. En el trabajo descrito en la referencia [12] se propone una técnica para cuantificar la forma en que el marco es utilizado y mediante comparaciones estadísticas se evalúan los resultados obtenidos. Además se presenta una serie de herramientas desarrolladas para este fin, así como algunas opciones de métricas para evaluar la información obtenida. La observación expuesta por los autores es que actualmente existe una gran variedad de herramientas que ayudan a entender cómo utilizar un marco pero no existe ninguna herramienta que permita evaluar los resultados obtenidos. Para este fin se presenta la herramienta SEA que analiza el marco mediante especificaciones de UML y almacena la información histórica en una base de datos. Esta herramienta no genera conclusiones sobre la calidad pero si proporciona información para la evaluación humana. Además debido a la gran información generada se presenta otra herramienta para el manejo de esta información. 2.1.2.5. Análisis de Conceptos Formales (ACF) como Soporte para la Construcción de Frameworks de Dominio En el trabajo descrito en la referencia [7] se presenta un proceso de construcción de frameworks de dominio, soportado por herramientas que integran la estrategia de iniciar con la elaboración previa de un conjunto de aplicaciones del dominio, con las técnicas que facilitan la evolución posterior del marco, tanto para mejorar su capacidad de instanciar aplicaciones del dominio como para adaptarse a las variaciones que indudablemente han de producirse en los requisitos del mismo. De toda la arquitectura propuesta, hasta el momento de su publicación sólo se cuenta con las herramientas de análisis de herencia y cliente a partir de código fuente en el lenguaje Eiffel, y se encuentran en fase final las mismas herramientas, pero partiendo de código Java y C++.

11

Capítulo 2. Antecedentes Para probar el funcionamiento de la herramienta y por lo tanto del procedimiento se utilizó la biblioteca estándar de SmallEiffel que proporciona la funcionalidad básica de entrada y salida de datos. 2.1.2.6. Líneas de Productos, Componentes, Frameworks y Mecanos En el trabajo descrito en la referencia [8] se presentan los principales elementos reusables de grano grueso, relacionándolos con los métodos de ingeniería de dominio y con las líneas de productos. De los trabajos presentados hasta ahora, [9] y [11] se enfocan a problemas que se pueden presentar en la composición y reuso de los marcos orientados a objetos. En [10] y [7] se presentan mecanismos para el diseño y construcción de marcos orientados a objetos. En [12] se aborda el problema de la falta de entendimiento del uso del marco y proponen una evaluación por medio de información histórica referente al marco. Por último en [8], se presentan los conceptos básicos para entender el diseño y la arquitectura de un marco. Se revisaron en total 20 trabajos referentes al tema de marcos orientados a objetos, de los cuales se eligieron los 6 mencionados anteriormente por dar una idea clara de la variedad de áreas en las que se está trabajando sobre este tema. Como se puede observar, en estos trabajos no se desarrolla un proceso de migración de MOO’s hacia servicios Web. Por el momento este campo no está siendo tratado por los investigadores de los marcos orientados a objetos. El rumbo que se está tomando es diferente al propuesto en este proyecto de tesis. 2.1.3. Historia de los Sistemas Distribuidos 2.1.3.1. Programación Basada en Componentes (por sus siglas en inglés CBP) Con el objetivo de obtener piezas de reuso menos robustas y más sencillas de reusar surge la programación basada en componentes. Su objetivo principal es construir un mercado global de componentes de software en el que los usuarios son los propios desarrolladores de aplicaciones que necesitan reusar componentes ya hechos y probados para construir sus aplicaciones de forma más rápida [13]. La CBP aparece como una variante natural de la programación orientada a objetos para los sistemas abiertos, en donde la programación orientada a objetos presenta algunas limitaciones. Tales como, no permite expresar claramente la distinción entre los aspectos computacionales y meramente composicionales de la aplicación; no define una unidad concreta de composición independiente de las aplicaciones; y define interfaces de muy bajo nivel para que sirvan de contratos entre las distintas partes que deseen reutilizar objetos [13]. La unidad básica de este modelo es el componente, el cual se define como una unidad de composición de aplicaciones de software que posee un conjunto de interfaces y de requisitos que ha de poder ser desarrollado, adquirido, incorporado al sistema y compuesto con otros componentes de forma independiente, en tiempo y espacio [14].

12

Capítulo 2. Antecedentes El paradigma de ensamblar componentes y escribir código para hacer que estos componentes funcionen se conoce como Desarrollo de Software Basado en Componentes (por sus siglas en inglés CBD) [14]. El uso de este paradigma posee algunas ventajas:

1. Reuso del software. Permite alcanzar un mayor nivel de reuso de software. 2. Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada uno de

los componentes antes de probar el conjunto completo de componentes ensamblados. 3. Simplifica el mantenimiento del sistema. Cuando existe un bajo acoplamiento entre

componentes, el desarrollador es libre de actualizar y/o agregar componentes según sea necesario, sin afectar otras partes del sistema.

4. Mayor calidad. Dado que un componente puede ser construido y luego mejorado continuamente por un experto u organización, la calidad de una aplicación basada en componentes mejorará con el paso del tiempo.

Los inconvenientes que presenta el modelo orientado a componentes (por sus siglas en inglés COM) son básicamente los mismos que el de MOO’s, excepto por el problema de acoplamiento, ya que los componentes son unidades autónomas de software que pueden ser usados de manera independiente. Con el surgimiento de los sistemas distribuidos se presenta una nueva etapa en el proceso de reuso de los sistemas de información. Esta evolución tecnológica y de búsqueda de soluciones a la computación distribuida no es un problema reciente [15]. En los 80’s el protocolo de comunicación no era objeto de interés de los desarrolladores. Era suficiente con realizar aplicaciones que dentro de una misma máquina se comunicaran entre sí. En los 90’s alcanzaron popularidad objetos como COM (Componet Object Model) introducido por Microsoft y CORBA (Common Object Request Broker Architecture) introducido por la OMG (Object Management Group) [16]. Los sistemas distribuidos surgen para dar solución a las necesidades de compartir recursos, ya sea en forma de software o de hardware. Un sistema distribuido consiste en una colección de computadoras autónomas unidas por una red y con un sistema que les permite compartir recursos de hardware, software y datos [17] Los dos tipos principales de sistemas distribuidos son: los sistemas computacionales distribuidos y los sistemas de procesamiento paralelo. En programación distribuida, un conjunto de computadoras conectadas por una red son usadas colectivamente para realizar tareas distribuidas. Por otro lado en los sistemas paralelos, la solución a un problema importante es dividida en pequeñas tareas que son repartidas y ejecutadas para conseguir un alto rendimiento.

13

Capítulo 2. Antecedentes Los sistemas distribuidos se pueden implementar usando dos modelos: el modelo cliente/servidor y el modelo basado en objetos. El modelo cliente/servidor contiene un conjunto de procesos cliente y un conjunto de procesos servidor. Se precisan además de algunos recursos de software. Todos estos recursos son manejados por los procesos servidor. El cliente y el servidor deben hablar el mismo lenguaje para conseguir una comunicación efectiva. El primero solicita al segundo algunos recursos y este último los concede, le hace esperar o lo deniega según los permisos que tenga [18]. En el modelo distribuido orientado a objetos hay una serie de objetos que solicitan servicios a los proveedores a través de una interfaz de encapsulamiento definida. Un cliente envía un mensaje a un servidor y éste decide qué ejecutar. 2.1.3.2. COM (Component Object Model) y DCOM (Distributed Component Object Model) La tecnología OLE de Microsoft surgió en 1990 para dar la capacidad de “cortar y pegar” a los entornos Windows. Esta especificación se extendió a OLE2, para permitir comunicaciones más generales, como la funcionalidad de “arrastrar y soltar”. Posteriormente, OLE2 pasó a conocerse como COM. COM empezó a promoverse como una infraestructura genérica para la comunicación entre componentes [19]. El siguiente paso fue extender esta infraestructura a varias máquinas, de lo que surgió el modelo DCOM. A finales de 1995, cuando Microsoft decidió cambiar su estrategia respecto a Internet, DCOM pasó a conocerse como ActiveX, pero sólo como una parte de ActiveX, nombre en el que se incluyeron múltiples tecnologías necesarias para constituir la llamada plataforma activa [16]. El modelo DCOM es un sistema de componentes implementado en todos los sistemas que fabrica Microsoft, el cual define cómo los componentes y sus clientes interactúan entre sí. La interacción es definida de tal manera que el cliente y el componente se pueden conectar sin la necesidad de un sistema intermedio. El cliente llama a los métodos del componente sin tener que preocuparse de niveles más complejos [16].

El modelo DCOM permite realizar llamadas a objetos remotos utilizando varios

lenguajes de programación. Soporta interfaces múltiples escritas en un lenguaje IDL similar al C++. También soporta la recolección distribuida de basura. El protocolo de intercambio de información es el Object Remote Procedure Call (ORPC).

El inconveniente que presenta DCOM es que está ligado a los sistemas operativos de

Microsoft, aunque existen implementaciones para Unix, y Apple Macintosh.

14

Capítulo 2. Antecedentes 2.1.3.2. CORBA (Common Object Request Broker Architecture) El modelo CORBA, es una tecnología para crear sistemas distribuidos, desarrollada por un consorcio de fabricantes agrupados bajo la OMG. El estándar CORBA define que se debe de incluir una implementación estándar, pero no define cómo se tiene que hacer, por lo que la tarea se deja de la mano de los diferentes fabricantes. Una de las principales características de CORBA es permitir una total libertad a los implementadores siempre que éstos respeten algunos aspectos orientados a la interoperabilidad entre implementaciones. Algunas de las ventajas que proporciona el modelo CORBA son [15]: 1) Disponibilidad y Versatilidad: Muchas arquitecturas y sistemas operativos cuentan con una implementación de CORBA, lo que hace suponer que se puede usar CORBA en cualquier proyecto de sistemas distribuidos. 2) Adaptación a Lenguajes de programación: Es posible emplear los servicios de CORBA desde cualquier lenguaje de programación, desde C++, C ó Java, Cobol ó Ada. Los Inconvenientes que presenta este modelo son [15]: 1) Complejidad Permitir la interoperabilidad de distintos lenguajes, arquitecturas y sistemas operativos lo que hace que sea un estándar bastante complejo, y su uso no sea tan transparente al programador como sería deseable:

a) Hay que usar un compilador que traduce una serie de tipos de datos estándar a los tipos del lenguaje en el que se vaya a programar (IDL). IDL (Interface Definition Language) es un lenguaje de programación pensado exclusivamente para especificar los interfaces de las clases cuyas instancias queremos hacer públicas a objetos remotos que las usarán como clientes. La necesidad de un IDL viene dada por la independencia de CORBA respecto a la arquitectura y al lenguaje de programación [15]. IDL pone de acuerdo a distintos lenguajes en el formato y tamaño de sus especificaciones. El compilador de IDL transforma una especificación neutral para la plataforma y el lenguaje, en otra especificación que se puedan enfocar.

b) Se debe de ser consciente a la hora de diseñar qué objetos van a ser remotos y cuáles no (los remotos sufren restricciones en cuanto a sus capacidades con respecto a un objeto normal). c) Es necesario emplear tipos de datos que no son: los que proporciona de manera habitual el lenguaje de programación (muchas veces hay que emplear tipos de datos adaptados de IDL).

15

Capítulo 2. Antecedentes 2) Incompatibilidad entre implementaciones Muchas empresas ofrecen implementaciones CORBA, si bien el grado de cumplimiento es diverso. Las divergencias entre ORBs radican en detalles que, aunque no hacen imposible aplicar en uno el mismo diseño de un programa pensado para otro, hacen que la adaptación sea fastidiosa. Cuestiones como la colocación de librerías o las diferentes formas de implementar la gestión de la concurrencia, hacen difícil la portabilidad del código y obligan al programador a reciclarse cuando quiere cambiar de ORB. Además, donde el estándar no concreta, las implementaciones pueden variar entre sí, lo que da lugar a molestas incompatibilidades que complican la vida al usuario. 2.1.3.3. RMI (Remote Method Invocation) RMI fue el primer framework con la idea de crear sistemas distribuidos que apareció para Java. La invocación de métodos remotos permite que un objeto que se ejecuta en una máquina virtual de Java pueda invocar métodos de un objeto que se encuentra en ejecución bajo el control de otra máquina virtual de Java. RMI permite crear e instanciar objetos en máquinas locales y al mismo tiempo crearlos en otras máquinas remotas, de forma que la comunicación se produce como si todo estuviese local. RMI se convierte así en una alternativa muy viable a los sockets de bajo nivel con una serie de particularidades destacables [19]: - Permite abstraer las interfaces de comunicación a llamadas locales. No se requiere poner en el protocolo. Y las aplicaciones distribuidas son de fácil desarrollo. - Es flexible y extensible, destaca su recolector de basura. -Stub/skeleton: es responsable de transferir datos a la capa Remote Reference Layer (RRL), permite a los objetos java ser transmitidos a diferentes espacios de direcciones. - RRL es responsable de crear independencia de los protocolos. - Transport Layer es responsable de establecer las conexiones a los espacios remotos de direcciones. En RMI toda la información sobre los servicios del servidor se dan en una definición de interfaz remota.

16

Capítulo 2. Antecedentes Un inconveniente de utilizar RMI es que sólo funciona para aplicaciones realizadas en lenguaje Java. 2.1.3.4. Arquitectura Orientada a Servicios y Servicios Web Los servicios Web surgen debido a los diversos inconvenientes encontrados en las plataformas que en su momento existieron y con el objetivo de estandarizar la comunicación entre distintas plataformas (PC, Mainframe, Mac) y lenguajes de programación (PHP, C#, Java, etc.). Anteriormente se habían realizado intentos de crear estándares pero fracasaron o no tuvieron suficiente éxito. Los servicios Web surgieron para finalmente poder lograr la tan esperada comunicación entre diferentes plataformas. En la actualidad muchos sistemas legados están pasando a ser servicios Web. El concepto de servicio no es nuevo, pero la noción de Arquitectura Orientada a Servicios (por sus siglas en inglés SOA) ha evolucionado a través de los últimos años. SOA es un estilo de arquitectura de software que promueve el desacoplamiento entre componentes, de forma que puedan ser reusados. SOA es un concepto abstracto, el cual se rige exclusivamente por los principios de Orientación a Servicios [20]. El elemento básico de SOA es el servicio. Un servicio Web es una aplicación que puede ser descrita, publicada, localizada, e invocada a través de una red, generalmente Internet [14]. Los servicios Web están formados por diferentes tecnologías y por ello son varias las organizaciones que participan en su gestión. Concretamente son tres las organizaciones involucradas [20]: W3C (World Wide Web Consortium): Encargado de la estandarización de HTML y XML. Referente a los servicios Web. Es el encargado de gestionar el protocolo de comunicación de los servicios Web (SOAP), y el lenguaje de descripción de interfaces (WSDL). Más recientemente, W3C también se ha dedicado a estandarizar algunas de las extensiones WS-* de los servicios Web. Concretamente se encarga de WS-CDL (Web Services Choreography Description Language) y de WS-Addresing. OASIS: Anteriormente conocida como SGML Open, cambió su nombre para redirigir sus acciones de SGML hacia XML. Esta organización es bastante conocida por gestionar dos tecnologías muy conocidas. Es el encargado de desarrollar el estándar UDDI para el registro de servicios Web. También se encarga de gestionar la especificación ebXML el cual es un estándar para el intercambio de datos entre aplicaciones B2B.

17

Capítulo 2. Antecedentes Actualmente se encarga de desarrollar extensiones WS-* para los servicios Web. Estas extensiones son WS-BPEL creada para la orquestación de servicios Web y WS-Security para todos los aspectos relacionados con la seguridad. WS-I (Web Services Interoperability): Este organismo es reciente (apareció en 2002) y su principal objetivo es asegurar que se utilizan los estándares adecuados y no definirlos ni desarrollarlos. Por ello, este organismo ha definido un documento llamado perfíl básico (Basic Profile), donde se indican cuáles son los estándares que se deberían utilizar para diseñar arquitecturas interoperables. Es decir, este documento es utilizado como mecanismo para generar arquitecturas SOA "compliant". Actualmente, también se han preocupado por un aspecto tan importante como la seguridad y han publicado un perfíl de seguridad básico (Security Basic Profile) cuya finalidad es la misma que el perfil anterior, pero relacionado con la seguridad. El concepto de servicios Web viene a revolucionar las aplicaciones empresariales. La mayoría de las compañías buscan actualmente migrar hacia nuevas tecnologías con el propósito de mantener su competitividad. Si no lo hacen es más difícil integrarse con el comercio de los sistemas del negocio. Los servicios Web prometen flexibilidad, y unir de manera eficiente las aplicaciones de la empresa.

La ventaja principal de los servicios Web es que permiten trabajar a través de diversas plataformas y modelos de programación. La diferencia entre CORBA y los servicios Web es que CORBA depende de un lenguaje de definición de interfaces (IDL) mientras que los servicios Web dependen de un protocolo simple de acceso a objetos (SOAP).

Otra ventaja de los servicios Web es su amplia aceptación por la mayoría de los

vendedores incluyendo IBM, Microsoft, Sun y otros. Son más flexibles que otras tecnologías porque están construidos utilizando el protocolo SOAP el cual es derivado de XML. Permiten compartir la lógica de negocios, información y procesos a través de una Interfaz para un ambiente Web.

A diferencia de los modelos tradicionales cliente/servidor, tales como servidor Web /

sistema de páginas Web, los servicios Web no proveen al cliente de una Interfaz gráfica de usuario, sólo proveen una funcionalidad específica. Los desarrolladores pueden agregar una Interfaz gráfica de usuario para utilizarlos como una página Web o un programa ejecutable [17].

Las características con las que debe de cumplir un servicio Web son [21]: 1) Ser reusables. Todo servicio debe ser diseñado y construido pensando en su reuso dentro de la misma aplicación, dentro del dominio de aplicaciones de la empresa o incluso dentro del dominio público para su uso masivo.

18

Capítulo 2. Antecedentes 2) Proporcionar un contrato formal. Todo servicio desarrollado, debe proporcionar un contrato en el cual figuren: el nombre del servicio, su forma de acceso, las funciones que ofrece, los datos de entrada de cada una de las funciones y los datos de salida. 3) No deben de tener estado. Un servicio no debe guardar ningún tipo de información. Esto es así porque una aplicación está formada por un conjunto de servicios, lo que implica que si un servicio almacena algún tipo de información, se pueden producir problemas de inconsistencia de datos. La solución, es que un servicio sólo contenga lógica y que la información esté almacenada en algún sistema de información del tipo que sea. 4) Ser autónomos. Todo servicio debe tener su propio entorno de ejecución. De esta manera el servicio es totalmente independiente y se puede asegurar que podrá ser reutilizable desde el punto de vista de la plataforma de ejecución. 5) Deben de poder ser descubiertos. Todo servicio debe poder ser descubierto de alguna forma para que pueda ser utilizado, consiguiendo así evitar la creación accidental de servicios que proporcionen las mismas funcionalidades. En el caso de los servicios Web, el descubrimiento se logrará publicando las interfaces de los servicios en registros UDDI. 6) Tener bajo acoplamiento. Es decir, que los servicios tienen que ser independientes unos de los otros. Para lograr ese bajo acoplamiento, lo que se hará es que cada vez que se vaya a ejecutar un servicio, se accederá a él a través del contrato, logrando así la independencia entre el servicio que se va a ejecutar y el que lo llama. Si se consigue el bajo acoplamiento, entonces los servicios podrán ser totalmente reutilizables. 7) Servicios abstractos de lógica subyacente. También referido como la abstracción a nivel de interfaz de servicio. Este es el principio que permite a los servicios actuar como cajas negras, ocultando sus detalles al mundo exterior. El alcance de lógica representada por un servicio influye considerablemente en el diseño de sus operaciones y su posición dentro de un proceso. 8) Deben permitir la composición: Todo servicio debe ser construido de tal manera que pueda ser utilizado para construir servicios genéricos de más alto nivel, el cual estará compuesto de servicios de más bajo nivel. En el caso de los servicios Web, esto se logrará mediante el uso de los protocolos para orquestación (WS-BPEL) y coreografía (WS-CDL). Como se mencionó, anteriormente, el elemento esencial de SOA es el servicio, pero únicamente con este concepto, no se puede diseñar una arquitectura SOA. Los cuatro elementos básicos necesarios para construir un Arquitectura Orientada a Servicios son [21]:

1. Operación. Es la unidad de trabajo o procesamiento en una arquitectura SOA. 2. Servicio. Es un contenedor de lógica. Estará compuesto por un conjunto de

operaciones, las cuales ofrecerá a sus usuarios. 3. Mensaje. Para poder ejecutar una determinada operación es necesario un conjunto de

datos de entrada. A su vez, una vez ejecutada la operación, ésta devolverá un resultado. Los mensajes son los encargados de encapsular esos datos de entrada y de salida.

19


4. Procesos de negocio. Son un conjunto de operaciones ejecutadas en una determinada secuencia (intercambiando mensajes entre ellas) con el objetivo de realizar una determinada tarea.

Las características más sobresalientes en los modelos distribuidos analizados, se muestran en la Tabla 2.

Tabla 2. Características de los modelos distribuidos. DCOM CORBA RMI SERVICIOS

WEB COMPAÑÍA MICROSOFT OMG SUN W3C

LENGUAJE DE PROGRAMACIÓN

C++, VB, VJ, PASCAL, C# MULTIPLE JAVA MULTIPLE

PLATAFORMA WIN 32 MULTIPLE MULTIPLE MULTIPLE PROTOCOLO IP IIOP IIOP HTTP, SOAP

FORMATO DEL MENSAJE NDR CDR JAVA XML

LENGUAJE DE DESCRIPCIÓN ODL IDL JAVA WSDL

Las ventajas y desventajas presentadas por cada modelo se muestran en la Tabla 3.

Tabla 3. Ventajas y desventajas de los modelos distribuidos. VENTAJAS DESVENTAJAS

DCOM RECOLECTOR DE BASURA, DIVERSOS LENGUAJES PROPIETARIO DE MICROSOFT

CORBA DIFERENTES LENGUAJEA, ALTA EFICIENCIA

COMPLEJIDAD, COMPATIBILIDAD,

ESPECIFICACIÓN PESADA

RMI INNOVACIÓN DE MÉTODOS

REMOTOS MEDIANTE APPLETS, FACILIDAD PARA DESARROLLAR

APLICACIONES DISTRIBUIDAS

SOLO FUNCIONA CON LENGUAJE JAVA

SERVICIOS WEB DIFERENTES LENGUAJES,

DIFERENTES PLATAFORMAS, ESTANDARES MAS SIMPLES

ES UNA TECNOLOGÍA RECIENTE FALTA TRABAJAR

SOBRE ASPECTOS DE SEGURIDAD

Aunque la mayoría de los sistemas que se desarrollan en la actualidad nacen en una plataforma de servicios, hoy en día siguen existiendo muchas aplicaciones que siguen funcionando en antiguas plataformas, las cuales representan una gran inversión y soporte, por lo que las empresas prefieren seguir conservándolas como opción para mantener los beneficios de los sistemas existentes. Migrar sistemas legados a servicios Web es evolucionar tecnológicamente y mantener la competitividad, es por eso que han surgido diferentes técnicas para lograr este objetivo.

20

Capítulo 2. Antecedentes 2.1.4. Trabajos de Servicios Web Relacionados 2.1.4.1. Migrating Interactive Legacy Systems to Web Services En el trabajo descrito en la referencia [22] se presenta una metodología para lograr que las funcionalidades interactivas de los sistemas legados puedan ser accesibles también como servicios Web. El objetivo es solucionar el problema de interacción que se genera entre el usuario y el sistema al llevar un sistema legado a un servicio Web debido a la diferencia entre la interacción del usuario con un sistema legado (consulta/respuesta o formularios) y un servicio Web (petición/respuesta). Para lograr este objetivo, los autores desarrollaron una técnica de envoltura la cual se usa para interactuar con el sistema legado. La envoltura actúa como intérprete de un autómata finito, a través del cual se describe un modelo de interacción entre el usuario y el sistema legado. Este modelo es obtenido mediante técnicas de ingeniería inversa y técnicas de análisis de cajas negras. Como soporte a esta metodología se presenta un procedimiento de migración y una arquitectura de software. La limitación encontrada en este proyecto es que los modelos utilizados, como es el Screen Template y los modelos de autómatas finitos deben ser extraídos manualmente durante la fase de identificación. El caso de estudio utilizado para probar dicha metodología fue con el software legado orientado a terminales llamado Pine. 2.1.4.2. Migración de Sistemas de Información Legados a Servicios Web como Plataforma para lograr la Integración b2b En el trabajo descrito en la referencia [23] se expone el marco teórico necesario para llegar al desarrollo de una metodología que permita el proceso de migración utilizando fragmentos de código existentes y darles el tratamiento necesario para convertirlos en servicios Web, lo que brinda la oportunidad de aprovechar lo desarrollado en el sistema legado a nivel de la lógica del negocio y a nivel de programación como base para el nuevo sistema. Se muestran diferentes metodologías propuestas en trabajos anteriores y con base en ellas se extraen los métodos más comúnmente utilizados para llevar los sistemas legados a servicios Web como son: desarrollar la aplicación nuevamente utilizando servicios Web; seleccionar fragmentos de código probados y convertirlos en servicios o convertir la aplicación completa. 2.1.4.3. Generación Semi-automática de Servicios Web En el trabajo descrito en la referencia [24] se presenta Federica, una plataforma para la automatización de la creación de servicios Web a partir de aplicaciones Web. Federica genera descripciones WSDL aumentadas con información semántica de los servicios. El sistema genera además una implementación de los mismos que enlaza los métodos de éstos con llamadas a la aplicación Web original, de forma que los servicios se puedan ejecutar de forma inmediata. Para el análisis y descripción automática de la funcionalidad ofrecida por una aplicación Web, el sistema toma como entrada inicial la URL de la página Web de acceso a la aplicación. La generación automática de las descripciones WSDL, se basa en el análisis de los formularios de interfaz con la aplicación, a partir del cual se definen los diferentes métodos a ofrecer por el Servicio Web generado.

21

Capítulo 2. Antecedentes Para probar la plataforma federica los autores utilizaron como entrada la página inicial de Google (http://www.google.es). 2.1.4.4. Migrating COBOL Systems to the Web by using the MVC Design Pattern En el trabajo descrito en la referencia [25] se presenta una estrategia de migración para formar arquitecturas Web basadas en el patrón de diseño MVC (Modelo, Vista, Control). Además, los autores presentan un conjunto de herramientas que mediante la extracción de toda la información requerida de código en COBOL generan automáticamente, la envoltura para la lógica de negocio, el modelo de datos y en Java Server Pages la interfaz para el usuario. La estrategia y las herramientas forman parte de un proyecto de investigación llamado M&S SW dirigido a desarrollar nuevas soluciones tecnologías para trasformar pequeñas y medianas empresas que operan bajo información y comunicación tecnológica. Todas las herramientas fueron desarrolladas en Java y para probarlas se utilizó un código en cobol con 101 programas y 38,000 líneas de código. El principal problema encontrado en el caso de estudio, fue la generación automática del puente entre la interfaz y el modelo, obtenidos ambos a partir del análisis del código. La estructura del puente fue generada automáticamente dentro del componente Modelo del patrón de diseño MVC y extendida manualmente para llamar de forma correcta a la lógica del negocio. 2.1.4.5. Creating Web Services from Legacy Host Programs En el trabajo descrito en la referencia [26] se presenta un procedimiento soportado por una herramienta para extraer secciones de código legado seleccionadas y presentarlas con una interfaz en XML. La misma interfaz es utilizada para generar una clase en Java, la cual crea mensajes para ser enviados al servidor, así como para interpretar los mensajes XML provenientes de él. La herramienta fue diseñada para trabajar con código desarrollado en los lenguajes: PL/I en la que los fragmentos de código que puede elegir el usuario para convertir a servicios Web son procedimientos, COBOL en la que los fragmentos pueden ser secciones o párrafos y en C en la que se pueden elegir funciones o procedimientos. Las pruebas realizadas por los autores para esta herramienta fueron con un programa y un subprograma en COBOL provenientes ambos de sistemas bancarios, también se realizaron pruebas con módulos en el lenguaje C provenientes de un sistema de seguridad. Todas probadas con un cliente en Donet y el navegador Explorer 5.

2.1.4.5. Migration of Legacy Web Applications to Enterprise Java™ Environments – Net.Data® to JSP™ Transformation* En el trabajo descrito en la referencia [27] se presenta una metodología para lograr la migración de aplicaciones legadas basadas en IBM Net.Data a nuevos ambientes de desarrollos en plataforma Java. Para lograr este objetivo la aplicación Net.Data es refactorizada en JavaBeans (el modelo), en JSPs (la vista) y en un servlets (el control). Para evaluar la eficiencia de esta metodología presentan una herramienta que soporta la transformación automática de Net.Data a JSPs. Esta herramienta fue implementada y probada en una aplicación comercial de IBM. 2.1.4.6. Supporting Migration to Services using Software Architecture Reconstruction En el trabajo descrito en la referencia [28] se propone el uso de una arquitectura de reconstrucción para dar soporte a la modernización de sistemas, por medio de la identificación

22

Capítulo 2. Antecedentes y reuso de componentes legados que puedan ser llevados a servicios en una Arquitectura Orientada a Servicios. El primer paso presentado es la reconstrucción de la arquitectura, el proceso consiste en la reconstrucción o recuperación de la arquitectura de un sistema implementado a partir de su código. Para llevar acabo esta tarea se proponen herramientas tales como Understand (desarrollada por Scientific Tollworks Inc.) e Imagix 4D (desarrollada por Imagix Corporation). Una vez que se obtiene la información necesaria, se importa a ARMIN (por sus siglas en inglés: Minería y Reconstrucción de Arquitectura) una herramienta que analiza sistemas escritos en C, C++, Java y Fortran (desarrollada por Carnegie Mellon® Software Engineering Institute and the Robert Bosch Corporation). El siguiente paso es la identificación de dependencias, esto se puede lograr con el análisis del código, identificando llamadas entre funciones, variables globales, relaciones entre archivos, directorios, etc. Una vez que se tienen identificadas las dependencias, se procede a la identificación de componentes, comúnmente las organizaciones que quieren llevar componentes a servicios Web tienen previamente identificados cuáles son los componentes candidatos a ser migrados, si éste no fuera el caso, se proponen técnicas para lograr este objetivo. El último paso consiste en identificar las dependencias que existen entre los componentes seleccionados, la herramienta propuesta es ARMIN. La arquitectura fue probada con un sistema desarrollado en C++ por el DoD de Estados Unidos de América. Como conclusión proponen metas tales como probar la arquitectura con otras herramientas, incorporar reglas de decisión, entre otras. En este trabajo se estudia la forma de identificar los componentes de un sistema legado, que pueden ser reusados en una Arquitectura Orientada a Servicios. El proceso es muy similar al propuesto en este trabajo de tesis, debido a que antes de determinar si un marco de aplicaciones orientados a objetos puede ser dividido según las categorías o tareas incluidas en dicho marco, se deben de conocer las dependencias existentes en él, para de esta forma determinar si el marco puede o no ser separado. Las principales diferencias son:

1. No parten de un marco orientado a objetos. 2. Para analizar los componentes lo hacen por medio de herramientas ya existentes. 3. No desarrollan la separación de los componentes, solo identifican los posibles

candidatos a ser convertidos a servicios Web. 4. No realizan la transformación de los componentes a servicios Web.

Características finales: En el proceso de migración de sistemas legados hacia servicios Web, todos los trabajos analizados presentan diferentes técnicas para lograr este objetivo. En el trabajo descrito en la referencia [22] se propone una metodología soportada por un procedimiento y una arquitectura, desarrollada específicamente para llevar sistemas legados interactivos a servicios Web. El inconveniente observado en este trabajo es, que para lograr el proceso de migración se requiere de personas especializadas que conozcan acerca de

23

Capítulo 2. Antecedentes autómatas finitos, de Screen Templates y de herramientas para crear envolturas, esto debido a que todos los pasos se tienen que desarrollar de forma manual, lo que resulta muy complicado para personas que no tienen experiencia en estos procesos. En el trabajo descrito en la referencia [24] se presenta una plataforma para llevar páginas Web a servicios Web, el enfoque presentado es diferente debido a que no parten de sistemas legados ni de marcos orientados a objetos. En el trabajo descrito en la referencia [25] se presenta otra estrategia para migrar código legado a servicios utilizando el patrón de diseño MVC, el proceso es automático, pero las herramientas desarrolladas no están integradas, por lo que se debe de tener conocimiento de todas ellas, además la transformación se hace a partir de código legado y no de un marco orientado a objetos. Un aspecto importante en este trabajo, es que se hace un análisis y una separación de código legado procedural, lo cual tiene cierta similaridad con el trabajo aquí propuesto. En el trabajo descrito en la referencia [26] se presenta un procedimiento soportado por una herramienta para llevar fragmentos de código procedural en Cobol o en C a servicios Web, el procedimiento propuesto en este proyecto es muy similar al aquí planteado, debido a que se realiza un análisis para identificar que fragmentos de código del sistemas van a ser separados y convertidos a servicios. La diferencia consiste en que en el procedimiento propuesto en esta tesis no se realiza el análisis para identificar fragmentos de código que pueden ser llevados a servicios Web, debido a que se sabe de antemano que un marco es un componente reusable y por lo tanto cumple con las características para ser convertido en uno o varios servicios, sin embargo el análisis que se realiza es para llevar acabo la separación de las diferentes partes que integran el marco y de esta forma sustituir las relaciones de agregación por relaciones de composición de servicios Web, logrando con esto aumentar las posibilidades de reuso. Como se puede observar, en ninguno de los trabajos analizados se estudia la generación de servicios Web a partir de Marcos Orientados a Objetos. 2.2. Justificación Las principales ventajas que ofrecen los MOO’s son: la reducción de costos de los procesos de desarrollo de aplicaciones de software para dominios específicos y la mejora de la calidad del producto final. La importancia de este proyecto radica en que mediante la aplicación del procedimiento desarrollado, será posible aprovechar algunos de los beneficios de los MOO’s de uso centralizado, pero ahora de forma distribuida, como por ejemplo: organizar servicios Web por dominios, escribir menos código para resolver aplicaciones de un dominio que cuente con servicios ya construidos para su reuso, así como características de independencia, autonomía y portabilidad.

Actualmente no existe alguna herramienta que realice de forma semi-automática la separación de los componentes que integran un marco orientado a objetos y los convierta en servicios Web. Para llevar a cabo este proceso se tendría que realizar de forma manual, lo que implica que el desarrollador deberá tener la habilidad y conocimiento para realizar la descomposición y recomposición de cada parte de un servicio Web, además, existe el riesgo de introducir defectos debido al proceso de conversión manual.

24


La separación de los componentes que integran un marco orientado a objetos permitirá que otras aplicaciones diferentes utilicen cualquiera de los componentes del marco aisladamente y no necesariamente tengan que utilizar el marco de forma completa, sino, sólo los componentes que sean de su interés.

2.3. Beneficios Los beneficios que esta tesis provee son:

• Un procedimiento que permita llevar los marcos orientados objetos hacia marcos de servicios Web, habilitando el reuso distribuido.

• Una herramienta prototipo de soporte al procedimiento para la transformación semi-

automática hacia marcos de servicios Web. Así, los desarrolladores de software tendrán a su disposición, a través de los servicios Web, los componentes de MOO’s en su aplicación completa o sólo aquellos componentes que requieran para el desarrollo de nuevas aplicaciones.

2.4. Planteamiento del problema Los MOO’s, además de las relaciones de herencia como mecanismos de extensión, utilizan el mecanismo de agregación, ya sea fuerte o débil, como relación de asociación para lograr la colaboración de los diferentes componentes de software que participan en la construcción de software de dominios de aplicaciones, como se muestra en la Figura 1.

Figura 1. Marco orientado a objetos del dominio de la estadística.

Como podemos observar este marco está integrado por cinco componentes diferentes: Uno es para el manejo de listas enlazadas, otro es para la ordenación de objetos, otro para

25

Capítulo 2. Antecedentes cálculos estadísticos de tendencia central, otro para cálculos estadísticos de dispersión y por ultimo el de contexto. Si este marco lo transformamos en un servicio Web con la funcionalidad que nos brindan sus cinco componentes, estos componentes quedarían fuertemente acoplados, produciendo un problema de inmovilidad. Si todo el marco fuera transformado a un servicio Web, el problema que se tendría es que no sería posible reutilizar de manera aislada a cualquiera de los componentes que integran a dicho marco. El uso de su funcionalidad tendría que hacerse con la totalidad del marco como un sólo servicio Web, debido a que el servicio tal como está, no puede ser utilizado de manera fragmentada en cualquiera de sus componentes principales. Por ejemplo, si tuviéramos la necesidad de reutilizar la lista enlazada en otro dominio de aplicaciones que no fuera el cálculo estadístico, tendríamos que utilizar el servicio en su totalidad con todas la funcionalidades con que cuenta actualmente el servicio, por lo que antes tendríamos que desacoplar los componentes y posteriormente integrar las partes necesarias para resolver la aplicación del desarrollo. 2.5. Objetivo El objetivo de la tesis es diseñar un procedimiento que permita llevar marcos orientados objetos hacia marcos de servicios Web. 2.6. Solución del Problema Para resolver este problema se creó un procedimiento soportado por una herramienta semi-automática de reingeniería MOO2MSW, la cual analiza el código de los marcos orientados a objetos con ayuda de un analizador sintáctico de Java. Con base en los resultados obtenidos en la fase de análisis, se determina el criterio para separar las clases que integran al MOO según la arquitectura que presente. Una vez que se identifica y aplica el criterio de separación, se generan los servicios Web. Si en algún momento las clases requieren colaborar entre sí a nivel de servicio, se aplica la integración de aplicaciones. 2.7. Alcances y Límites 2.7.1. Alcances Los alcances obtenidos en el desarrollo del procedimiento y la herramienta desarrollada para dar soporte al procedimiento, se listan a continuación:

• El procedimiento y la herramienta de soporte desarrollados contemplan los siguientes

escenarios: a) Relaciones de herencia: 1. Atributos y métodos privados en la clase base. 2. Atributos y métodos públicos o protegidos en la clase base.

26


3. Atributos y método friendly. 4. Llamada al constructor de la clase padre con un Super. 5. Clases abstractas y métodos abstractos. 6. Interfaces.

b) Relaciones de asociación y agregación. 1. Relaciones de asociación. 2. Relaciones de agregación débiles. 3. Relaciones de agregación fuertes. Para cada escenario analizado se proponen técnicas para separar las partes que integran a un MOO, determinando según su arquitectura, los diferentes servicios Web posibles a generar. Los escenarios no contemplados son:

1. Atributos y métodos estáticos. 2. Clases derivadas que extienden e implementan a otras clases al mismo tiempo. 3. Métodos, atributos y clases tipo final.

• Las características soportadas por el procedimiento están basadas en los principios de

la programación orientada a objetos por lo que pueden ser escaladas a otros lenguajes de programación que sigan los mismos principios orientados a objetos que el lenguaje Java.

• El analizador sintáctico que realiza el análisis del código del MOO extrae las

siguientes características de cada una de sus clases:

1. Nombre de la clase. 2. Directorio en el que se ubica. 3. Modificador de acceso (privado, público, protegido o friendly). 4. Si contiene métodos ó atributos públicos. 5. Tipo de clase (base, interfaz, heredada o implementación). 6. Si contiene ó no relaciones de agregación hacia otras clases y cuáles son esas

clases. 7. Si contiene llamadas al constructor de la clase base. 8. Si se trata de una clase derivada identifica cuál es el nombre de la clase padre.

• La herramienta MOO2MSW (Marcos Orientados a Objetos hacia Marcos de Servicios

Web), realiza de forma automática la etapa de análisis y separación del procedimiento. También permite la conversión automática de las clases bases no extendidas y sin relaciones de agregación hacia servicios Web, así como las jerarquías de herencia en las que la clase base es una interfaz y sus clases derivadas son implementaciones. Además contiene un apartado en el que el usuario puede agregar las clases que desee convertir a servicios Web, tomando en cuanta que en este apartado la herramienta no realiza validaciones sobre el contenido de la clase, únicamente se encarga del proceso de conversión.

27

Capítulo 2. Antecedentes 2.7.2. Limitaciones En esta sección se mencionan las limitaciones que presentan la herramienta y el procedimiento desarrollados:

• La fase de análisis del procedimiento contempla únicamente los escenarios

mencionados en el apartado de alcances. Se propone analizar en trabajos futuros nuevos escenarios, por ejemplo: atributos y métodos estáticos; clases que derivan e implementan al mismo tiempo; clases, métodos y atributos finales, entre otros.

• El análisis de escenarios se limitó específicamente para marcos desarrollados en el

lenguaje de programación Java, por lo que pueden ser distintos a los que se presentan en marcos desarrollados en otros lenguajes de programación.

• La herramienta no se encarga de mejorar ni agregar funcionalidad al marco, si el

usuario desea hacerlo, debe utilizar sus propios medios. • La herramienta no fue desarrollada para verificar los errores lógicos ni sintácticos que

pudiera contener el código del marco. Es responsabilidad del usuario verificar que el código que se va a analizar esta libre de errores.

• La herramienta trabaja únicamente con marcos desarrollados en código Java, por lo

que no se puede utilizar para transformar marcos desarrollados en otros leguajes de programación.

• Esta tesis parte del supuesto de que un marco orientado a objetos es el producto de un

análisis e ingeniería de dominios, por lo tanto, se tiene conocimiento de cuáles entidades de software pertenecen a un dominio y cuales pertenecen a otro. En caso de no contar con esta información, se propone identificar manualmente las clases de cada directorio.

• El módulo de generación de servicios Web de la herramienta no genera de forma

automática la conversión de jerarquías de herencia completas a servicios Web, para lograr este proceso el usuario debe hacerlo de forma manual o extender el funcionamiento del módulo de generación de servicios Web de la herramienta MOO2MSW para que realice esta actividad de forma automática. El mismo caso es para la implementación de técnicas de serialización y deserialización. Para facilitar al usuario estas tareas, la herramienta muestra en pantalla como se conforman las jerarquías de herencia en el marco.

• El módulo de integración de servicios Web de la herramienta no se desarrolla de forma

automática, por lo que el usuario debe de hacerlo de forma manual o extender el módulo de integración de servicios Web de la herramienta para que cumpla con la integración automática. Para facilitar al usuario esta tarea, la herramienta muestra en pantalla las relaciones de agregación existentes en el marco.

28


• La herramienta no verifica que las clases que forman a un servicio sean las esperadas por el usuario, eso depende exclusivamente de la arquitectura original del marco.

• La herramienta fue desarrollada y probada bajo la plataforma Windows, por lo que su

uso en otras plataformas queda fuera del alcance de la tesis.

29

Capítulo 3. Marco Teórico

Capítulo 3) MARCO TEÓRICO

En este capítulo se presentan algunos conceptos relevantes para el proceso de migración de MOO’s a MSW’s. 3.1. Marco Orientado a Objetos

La orientación a objetos surge como una evolución de la programación estructurada, la cual permite el planteamiento de un programa como una modelación de los elementos del mundo real. Esta aproximación permite desarrollar aplicaciones de gran complejidad, facilitando su reutilización y modificación. Al mismo tiempo, pueden ser gestionadas por un equipo de trabajo heterogéneo de manera flexible y eficiente [29]. La programación orientada a objetos es un paradigma de programación que define los programas en términos de "clases de objetos", objetos que son entidades que combinan

30

Capítulo 3. Marco Teórico atributos (datos), comportamiento (procedimientos o métodos) e identidad (propiedad del objeto que lo diferencia del resto) [30]. Las características más importantes de la programación orientada a objetos son: Abstracción de datos: Empaqueta una estructura de datos junto con un conjunto de operaciones asociadas a ésta. Esta propiedad habilita el ocultamiento y encapsulado de datos. Encapsulamiento: Cada objeto está aislado del exterior, es un módulo natural, y cada clase de objetos expone una interfaz a otros objetos que especifica cómo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificación por quien no tenga derecho a acceder a ellas, solamente los propios métodos internos del objeto pueden acceder a sus atributos para cambiar su estado. Polimorfismo: Se refiere a que un objeto efectúa ciertas acciones cuando recibe un mensaje. Ante un mensaje, el método que se ejecutará no sólo depende del nombre del mensaje, sino también del tipo de objeto en particular. Esto da la facilidad de que un objeto actúe de distintas maneras dependiendo del subtipo de la clase que responda a un mensaje.

Herencia: Permite especializar o extender la funcionalidad de una clase, derivando de ella nuevas clases de objetos. Una clase derivada hereda algunos de los miembros de la clase base y puede acceder a los que son públicos y protegidos como si fueran miembros de ella misma. Una clase derivada puede a su vez ser una clase base, dando lugar a una jerarquía de clases. Un aspecto importante en la programación orientada a objetos es la forma en que las clases se encuentran relacionadas, gran parte de esta relación se hace a través de la jerarquía de herencia. Una jerarquía de herencia es un conjunto de clases asociadas por la herencia de implementaciones, de interfaz y/o de clase, donde existen clases base o clases abstractas y clases derivadas o subclases. Una interfaz es una plantilla que define los métodos que serán implementados en las subclases. Una clase abstracta es aquélla cuyo propósito principal es definir una interfaz común para sus subclases. Una clase abstracta delega parte o toda su implementación en las operaciones definidas en sus subclases; de ahí que no se puedan crear instancias de una clase abstracta. Las operaciones que define pero no implementa la clase abstracta se denominan operaciones abstractas. Otra forma de relación entre clases son las relaciones de asociación. Una relación de agregación es un caso especial de asociación. Indica que una o más clases (clases componentes) forman parte de otra clase (clase compuesta). Las relaciones de agregación se clasifican en: Relación de agregación fuerte: Son aquellas clases cuya existencia depende de la existencia de otras clases. Por ejemplo si se tiene la clase Empresa y la clase Departamentos, la relación -una Empresa tiene varios Departamentos- es una relación fuerte, debido a que si se elimina la empresa los departamentos ya no tienen razón de existir. Relación de agregación débil: Son aquellas clases cuya existencia no depende de la existencia de otras clases. Por ejemplo si se tiene la clase Motor y se tiene la clase Auto, la existencia del

31

Capítulo 3. Marco Teórico auto con relación al motor, puede ser independiente. Si se destruye el auto, el motor puede seguir existiendo en otro auto, o como un objeto aislado. Con la herencia y la agregación se pueden crear dos tipos principales de componentes reusables orientados a objetos: las jerarquías de herencia y los MOO’s basados en dominios de aplicaciones [31]. Un MOO es un conjunto semi-completo de clases, en colaboración, que incorpora un diseño genérico el cual puede ser adaptado a una variedad de problemas específicos para producir nuevas aplicaciones hechas a la medida [1]. Está dirigido a unidades de negocios y/o dominios en particular. Los MOO’s permiten el reuso del diseño o las arquitecturas que dan solución a problemas recurrentes del dominio de aplicaciones. Además, pueden ser empacados como cajas blancas, grises o negras. Los beneficios principales que proporcionan los MOO’s son [32]: Modularidad: Mejora la modularidad encapsulando los detalles volátiles de implementación separados de las interfaces estables. La modularidad de un marco ayuda en la mejora de la calidad del software mediante la localización del impacto de diseño y cambios de implementación, reduciendo el esfuerzo requerido para entender y mantener el software existente. Reusabilidad: Las interfaces estables proporcionadas por los marcos de aplicaciones mejoran el reuso mediante la definición de componentes genéricos que pueden ser utilizados para el desarrollo de nuevas aplicaciones. Extensibilidad: Aumenta la extensibilidad, proporcionando métodos gancho explícitos (hooks), que atrapan nuevas funciones de aplicaciones específicas con las interfaces estables a nuevas funcionalidades. Los métodos gancho sistemáticamente desacoplan las interfaces estables del dominio de aplicaciones y las variaciones requeridas por la instanciación. Inversión de control. La arquitectura de ejecución de un marco de aplicaciones, es caracterizada por una “inversión de control”. Esta arquitectura indica los pasos del proceso de aplicaciones especificas, necesarios para el manejo de objetos que son invocados por el propio marco de aplicaciones. Algunas de las fases más importantes en el desarrollo de los MOO’s son las siguientes [9]:

Desarrollo del marco, normalmente es la fase que consume la mayoría del esfuerzo, produciendo diseños reusables y relaciones de implementación en un dominio. Los resultados más importantes de su fase son los modos de análisis del dominio y el MOO.

Uso del marco. El resultado de esta fase es una aplicación desarrollada por medio del

reuso de un marco. Aquí el ingeniero de software tiene que adaptar el marco existente por medio de la herencia desde las clases abstractas en el marco de aplicaciones.

32


Evolución y mantenimiento del marco, los marcos como todo software pueden estar sujetos a cambios. Las causas de estos cambios pueden ser errores reportados desde la aplicación, identificación de nuevas abstracciones debido a los cambios en el dominio del problema, entre otras. Como se puede observar, la meta principal de un MOO es permitir el reuso de su diseño y código en dominios de aplicaciones particulares, y ésto se logra utilizando la herencia y la instanciación. Otro objetivo de un MOO es facilitar la extensión de su funcionalidad, con el fin de cumplir con ciertos requerimientos necesarios para un problema particular del dominio; ésto también es logrado utilizando la herencia, agregando clases concretas que se conectan a las clases genéricas, las cuales ofrecen las interfaces del MOO. Sin embargo no siempre es posible lograr el reuso de los MOO’s, debido a que en ocasiones su arquitectura es muy compleja y resulta difícil entender su funcionamiento, sobre todo en los marcos que carecen de técnicas de documentación como método de reducción de la curva de aprendizaje. Otro contratiempo para su reuso ocurre cuando los marcos no maduros tienen problemas de diseño. Un mal diseño genera un alto grado de acoplamiento entre sus clases, impidiendo el reuso de las partes que integran al marco de forma independiente. A estos problemas son a los que está enfocada esta tesis cuyo objetivo es facilitar el uso de los MOO’s mediante su conversión a servicios Web, de tal forma que el usuario sólo requiera saber con qué operaciones cuenta y cuáles son las precondiciones y poscondiciones de cada método, solucionando el problema de la complejidad de la curva de aprendizaje, así como también dando más opciones a los usuarios al separar los componentes que integran al marco, para de esta forma obtener múltiples operaciones para problemas de un mismo dominio. 3.2. Servicios Web Los servicios Web son considerados un nuevo paradigma de programación distribuida, que permite integrar datos y procesos entre distintas aplicaciones, desarrolladas en diferentes lenguajes y plataformas. Un servicio Web es una aplicación que puede ser descrita, publicada, localizada, e invocada a través de una red, generalmente Internet [33]. Los servicios Web son componentes de caja negra debido a que el usuario no tiene que preocuparse por el funcionamiento interno del servicio, únicamente requiere saber qué funcionalidad ofrece, cuáles son los parámetros que reciben sus métodos y que valores son los que retorna. Los servicios Web están formados por 3 componentes principales los cuales se muestran en la Figura 2.

33


Descripciones de los servicios

Descripción del servicio

Servicio Enlazar

Registro

Proveedor del servicio

Cliente

Publicar (WSDL, UDDI)

Encontrar (WSDL, UDDI)

Figura 2. Componentes que forman un servicio Web.

• El proveedor del servicio: Es la parte que proporciona las aplicaciones de software, desarrolladas para necesidades específicas como los servicios. Los proveedores de servicio publican, dejan de publicar y ponen al día sus servicios de modo que estén disponibles en Internet. Desde una perspectiva de negocios, es el propietario del servicio. Desde una perspectiva arquitectónica, es la plataforma que sostiene el servicio.

• El cliente: Es la parte que tiene una necesidad la cual se puede satisfacer con la ayuda de

un servicio disponible en Internet. Desde el punto de vista de negocios el cliente es la empresa que solicita el servicio y desde el punto de vista de la arquitectura el cliente es la aplicación que busca e invoca un servicio o un servicio que requiere de otro servicio.

• El registro de negocios: Provee un depósito de descripción donde los proveedores

publican sus servicios y los consumidores obtienen servicios e información sobre ellos. Primero el proveedor crea un servicio y lo registra en la UDDI, posteriormente el consumidor busca un servicio que se adapte a sus necesidades. Una vez que lo localiza, accede a la descripción del servicio escrita en archivo WSDL, el cual se encuentra del lado del proveedor, por último, analiza el WSDL y crea un cliente para acceder al servicio. 3.2.1. Ventajas de los Servicios Web

• Las empresas que usan el modelo de servicios Web pueden proporcionar nuevos servicios

y productos sin la inversión y retraso que una empresa tradicional requiere. • Interoperabilidad: Cualquier servicio Web puede interactuar con otro servicio Web. • Fácil integración: promueven el desacoplamiento y la fácil integración de servicios. • Reducción de complejidad por encapsulamiento: Lo que importa es lo que proporciona el

servicio Web no cómo es implementado.

34

Capítulo 3. Marco Teórico • Es independiente de lenguaje y plataforma. Para conseguir la comunicación entre servicios es necesario contar con estándares definidos para llevar a cabo las operaciones de publicación, localización y enlace. 3.2.2. Estándares Asociados a los Servicios Web WSDL: Es un lenguaje basado en XML que se utiliza para describir y localizar servicios Web, define la interfaz del servicio y sus características de implementación. SOAP: Es un protocolo que se utiliza para iniciar las conversaciones con un servicio. Proporciona un mecanismo estándar para empaquetar mensajes. Simplifica el acceso a los objetos, permitiendo a las aplicaciones invocar métodos, objetos o funciones, que residen en sistemas remotos. Es independiente del lenguaje, modelo de objeto, sistema operativo y plataforma. UDDI: Es un registro público diseñado para almacenar información acerca de negocios y sus servicios de una forma estructurada. A través de la UDDI, se puede publicar y buscar información sobre dichos negocios y sus respectivos servicios Web. UDDI proporciona información técnica sobre los servicios de los negocios. 3.2.3. Herramientas para Desarrollar Servicios Web en Java 3.2.3.1. WASP (Web Application and Service Platform) Es una colección de herramientas que permite a los desarrolladores crear servicios Web de forma rápida y eficiente [34]. Esta formado por tres módulos: WASP Developer, WASP Server for Java y WASP UDDI. WASP Developer es una herramienta que permite la generación de servicios Web a través de aplicaciones existentes en Java o C++. Una gran ventaja es que el WASP Developer puede ser colocado como un plug-in en diferentes IDEs, como por ejemplo JBuilder y Eclipse. WASP UDDI ofrece un registro UDDI privado, de la misma forma que las herramientas de Sun y de IBM, con la ventaja de usar la especificación UDDI V2. WASP Server es un ambiente de desarrollo que permite trabajar con diferentes bases de datos, servidores de aplicaciones y servidores Web. 3.2.3.2. Apache Axis Apache Axis fue originariamente un producto de IBM Alphaworks, y fue posteriormente cedida a la Apache Foundation, que continuó desarrollándola bajo la licencia Apache. Para usar Apache Axis se requiere, además, Tomcat (el contenedor para Servlets de Apache) y Xerces (el analizador de XML de Apache) [35]. Axis se define como un framework de servicios Web basado en XML, el cual se compone de la implementación del servidor SOAP para Java y C++, así como también de una serie de librerías y API’s para generar y desplegar servicios Web. Se encarga de construir

35

Capítulo 3. Marco Teórico tanto la parte del servidor como la parte del cliente de servicios Web. Además incluye: un servlet que se integra con motores de servlets como Tomcat, soporte extensivo del estándar WSDL, una herramienta para generar clases Java a partir de WSDL, un conjunto de aplicaciones de ejemplo, una herramienta para el monitoreo de los paquetes TCP/IP . 3.2.3.3. JWSDP(Java Web Service Developer Pack) Es un framework integrado que contiene las librerías para trabajar con servicios Web desde Java [36]. JWSDP se puede integrar con los servidores de aplicaciones J2EE en forma de plugin. JWSDP fue desarrollado por Sun Microsystems en Enero de 2002 y tiene como objetivo reunir las tecnologías utilizadas por los servicios Web. Algunas de las tecnologías disponibles en JWSDP son: Java Servlets, JSPs (JavaServer Pages), JSTL (JSP Standard Tag Library), JAXM (Java API for XML Messaging), JAXP (Java API for XML Processing), JAXR (Java API for XML Registries), JAX-RPC (Java API for XML-based RPC) [37]. 3.2.3.4. Ant Ant no es una biblioteca de Java. Ant es una herramienta de construcción. Se incluye en el JWSDP porque hace más fácil escribir y empacar aplicaciones en Java. Tiene tareas para crear paquetes WAR (Web Application aRchive), los cuales son los paquetes por defecto de los servicios Web en Java. Ant es una herramienta desarrollada en Java y basada en XML para la construcción de programas (equivalente a make y makefiles) que permite llevar a cabo los distintos pasos del desarrollo de la aplicación. 3.2.3.5. JAXP (Java API for XML Processing) La API JAXP permite procesar documentos XML dentro de aplicaciones escritas en lenguaje Java. JAXP usa SAX (Simple API for XML Parsing) y DOM (Document Object Model) para el procesamiento de documentos, dando al usuario la posibilidad de elegir entre una representación de XML como un objeto o una manipulación de datos en forma secuencial. [38] Cuando un documento XML es procesado con una API SAX, se tiene una lectura o grabación secuencial de los elementos. Por otro lado, una API DOM ofrece una estructura en árbol para la representación de los elementos. La construcción de DOM precisa leer todo el documento XML y montar una jerarquía en memoria. El proceso inicia con la creación de una instancia del objeto SAXParser por medio de la clase SAXParserFactory. Para realizar la lectura es llamado el método parser( ), que a su vez puede llamar uno o más métodos definidos en una aplicación. Estos métodos son definidos por las siguientes interfaces: ContentHandler, ErrorHandler, DTDHandler y EntityResolver. 3.2.3.6. JAXR (Java API for XML Registries) JAXR ofrece una manera de acceder a registros de negocios a través de Internet. Estos registros son descritos como “páginas amarillas electrónicas” ya que contienen una lista de

36

Capítulo 3. Marco Teórico empresas y de los productos que ofrecen. JAXR permite que los desarrolladores puedan acceder esos registros UDDI utilizando para ello el lenguaje Java. La arquitectura de JAXR puede ser dividida en dos partes:

• JAXR Cliente, permite que los usuarios puedan acceder a los registros almacenados.

• JAXR proveedor, implementa diversas interfaces definidas por la especificación UDDI, con el objetivo de permitir que los clientes de los servicios Web puedan acceder a los registros.

3.2.3.7. JAX-RPC (Java API for XML-based Remote Procedure Calls) JAX-RPC es el API estándar de Java para implementar e invocar operaciones de servicios Web mediante el paradigma de los RPC’s principal para servicios Web [39]. JAX-RPC se basa en un mecanismo de llamadas a procedimientos remotos haciendo que los principales detalles de implementación sean invisibles tanto para el cliente como para el desarrollador del servicio Web. En JAX-RPC existe una herramienta que se utiliza para generar stubs utilizando documentos WSDL, el nombre de dicha herramienta es wscompile. También existe la herramienta wsdeploy que se utiliza para crear los enlaces (ties). La misma herramienta puede ser utilizada para crear los documentos WSDL. JAX-RPC no es restrictivo: un cliente puede acceder a un servicio Web que no esté escrito en el lenguaje Java y viceversa. Esta flexibilidad es posible gracias a que JAX-RPC utiliza tecnologías definidas por el W3C: HTTP, SOAP y WSDL. 3.2.3.8. JAX-WS (Java API for XML-Based Web Services) Es una parte importante de la plataforma Java J2EE, el cual se basa en las API JAX-RPC para facilitar la tarea de desarrollar servicios Web con tecnología Java. JAX-WS utiliza el protocolo SOAP para las envolturas, reglas de codificación, representación de invocaciones y respuestas de servicios Web transmitidos mediante mensajes en XML, HTTP y WSDL como formato para describir los servicios Web. 3.3. Integración de Aplicaciones Los servicios Web, permiten un alto grado de integración en las aplicaciones. Esta integración puede tener varios niveles, desde un nivel sencillo de integración, denominado servicios básicos o “e-servicios”, en el que las aplicaciones se integran con servicios Web. Hasta un nivel complejo de integración, denominado servicios compuestos o “e-workflow”, en el que la integración se produce en servicios compuestos de varios servicios sencillos (varios “e-servicios” forman el “e-workflow”).

37

Capítulo 3. Marco Teórico 3.4. Serialización de Objetos en Java La serialización de un objeto consiste en obtener una secuencia de bytes que represente el estado de dicho objeto. Esta secuencia puede utilizarse de varias maneras (puede enviarse a través de la red, guardarse en un fichero para su uso posterior, utilizarse para recomponer el objeto original, etc.). El estado de un objeto viene dado, básicamente, por el valor de cada uno de sus atributos. Así, serializar un objeto consiste, básicamente, en guardar el valor de cada uno de sus atributos. Si el objeto a serializar tiene atributos que a su vez son objetos, habrá que serializarlos primero. Éste es un proceso recursivo que implica la serialización de todo un árbol de objetos. Además, se almacena información relativa a dicho árbol, para poder llevar a cabo la reconstrucción del objeto serializado [41]. Para que un objeto sea serializable, debe implementar la interfaz java.io.Serializable. Esta interfaz no define ningún método. Simplemente se usa para marcar aquellas clases cuyas instancias pueden ser convertidas a secuencias de bytes (y reconstruídas posteriormente).

El proceso inverso de la serialización es la deserialización. La deserialización consiste en

obtener un objeto a partir de una secuencia de bytes.

38

Capítulo 4. Análisis de escenarios

Capítulo 4) ANÁLISIS DE ESCENARIOS

En este capítulo se describen los escenarios presentes en el proceso de separación de los componentes que integran a un MOO. También se definen las posibles alternativas de conversión a servicios Web para cada escenario, es decir, se determina qué clases o conjunto de clases pueden formar un servicio Web y si es necesario implementar la integración de aplicaciones entre servicios. Además se especifica cuáles de las alternativas presentadas son las que más se apegan a los principios de una Arquitectura Orientada a Servicios. Los escenarios que se presentan en la separación de un MOO, varían en base a aspectos como: • La arquitectura que presenta el marco. • La granulación deseada en la separación del marco. • El grado de acoplamiento entre las partes que se van a separar.

39

Capítulo 4. Análisis de escenarios Para identificar los escenarios, se tomaron ejemplos de arquitecturas existentes, definiendo los cambios que implica la separación de sus componentes. Además, se muestra la arquitectura antes y después del proceso de conversión. 4.1. Casos de Uso En la Figura 3 se presentan los casos de uso requeridos únicamente para el proceso de separación del MOO. Un diagrama completo de todos los casos de uso requeridos para hacer la conversión de MOOs a MSWs se muestra en la en el capítulo 6.

Figura 3. Diagrama de casos de uso para la conversión de los componentes de un MOO a servicios Web.

CU-1.1. Separar los componentes que integran a un MOO.

UsuarioCU-1. Convertir los componentes

de un MOO a servicios Web.

<<include>>

Para llevar a cabo el proceso de conversión de MOO’s a MSW’s, el actor “Usuario” que es la persona que realiza el procedimiento, tiene la opción de convertir los componentes de un MOO a servicios Web (la cual se representa con el caso de uso “CU-1”). Para llevar acabo esta opción es necesario que se realice la acción del caso de uso “CU-1.1” la cual consiste en separar los componentes que integran al MOO. 4.2. Definición de Escenarios Existe una pregunta muy importante para el proceso de transformación de un MOO a servicios Web. ¿Cómo decidir la granulación o tamaño de los servicios Web, escogidos a partir de un MOO? Las alternativas son:

1. Tomar el marco y convertirlo en servicio Web en su totalidad. Esta alternativa es la más sencilla de implementar, sin embargo no resuelve el problema planteado en el capítulo 2, donde se menciona la necesidad de utilizar únicamente algunos componentes del marco, por la arquitectura que presenta es necesario utilizar el marco en su totalidad.

40


2. Generar a partir del código del marco un diagrama de clases que permita al usuario visualmente decidir qué parte del marco es la que requiere utilizar de forma independiente, para posteriormente realizar de forma automática la separación y conversión del componente en un servicio Web. Para esta solución se requiere desarrollar una herramienta que a partir de ingeniería inversa genere de forma automática diagramas de clases, para lo que se estima un tiempo de desarrollo superior al disponible para este proyecto, es por eso que queda como una alternativa de solución para trabajos futuros. Otra opción es utilizar alguna de las herramientas ya existentes cómo Understan, Rational Rose, Enterpirse Architect e Imagix D4, por mencionar algunas, extender el código para que permita la selección interactiva de los componentes, y a partir de esta selección generar los servicios Web. Sin embargo ninguna de las herramientas mencionadas son de código libre y la información que manejan se guardan en una base de datos de formato propietario a la que únicamente a través de la herramienta se puede tener acceso.

3. Identificar las relaciones de agregación y sustituirlas por una relación de integración de

aplicaciones entre servicios. Esta alternativa es una idea nueva que abre un camino amplio de investigación, en la que se obtendrían servicios Web de un nivel de tamaño variado. Sin embargo, la dependencia entre servicios genera cierta deficiencia debido a que si un servicio falla, todos los que están integrados a él dejarán de funcionar.

4. Determinar el conjunto de clases de un servicio desde las clases que colaboran para

atender un caso de uso. Esta alternativa implica un riesgo debido a que pueden quedar servicios de un tamaño muy grande, por lo que tendría que aplicarse un criterio para determinar el tamaño de clases máximo permitidas en un servicio. Sin embargo tiene una ventaja, los servicios proporcionarían funcionalidad por sí solos sin tener que depender del uso de otros servicios.

La alternativa de solución elegida para el trabajo de tesis fue la número 3 que consiste en identificar las relaciones de agregación y sustituirlas por relaciones de integración de aplicaciones entre servicios. El motivo principal por el que se eligió esta alternativa fue por ser la idea principal con la que se planteo el proyecto de tesis, la cual permite formar las bases sobre el tema por ser el primero trabajo en su tipo en el cenidet, lo que permite adquirir experiencia para en trabajos futuros implementar las otras alternativas, las cuales surgieron a lo largo desarrollo de la tesis. Otra razón importante por la que se eligió esta alternativa fue el hecho de que es un proceso más completo de automatización en el que se requiere una mínima interacción con el usuario, por lo que el usuario no necesita ser experto en el tema para lograr el proceso de transformación. 4.2.1. Escenarios de la alternativa número 3 4.2.1.1. Escenario 1. Relaciones de Herencia

41

Capítulo 4. Análisis de escenarios 1) Atributos y métodos privados en la clase base. El modificador de acceso private tanto en atributos como métodos indica que se puede acceder a ellos únicamente desde la clase en la que esta definida. Por este motivo, si todos los atributos y métodos que se encuentran definidos en una clase base son privados, quiere decir que la clase derivada no puede acceder a ellos. Por lo tanto no existe una dependencia fuerte entre la clase base y la clase derivada. Un ejemplo de este escenario se muestra en la Figura 4.

Figura 4. Herencia con datos y métodos privados.

Ax : Integery : Integer

m()

B

B no usa a A, entonces cada clase puede ser un servicio separado e independiente. Ver la Figura 5.

Figura 5. Servicios Web A y B.

2) Atributos y métodos públicos o protegidos en la clase base. Una entidad de software con el modificador de acceso public indica que puede ser accedida por cualquier clase fuera o dentro del paquete. Por otra parte el modificador de acceso protected indica que puede ser accedida por la clase en la que esta definida y también por sus clases derivadas. Las clases derivadas tienen acceso a datos públicos o protegidos de la clase base, por lo tanto ambas clases deben permanecer unidas en un mismo servicio Web. Ver la Figura 6.

42


Aa : Floaty : Integer

m()n()

B

public float Multiplicar(){ return a*y;}

Figura 6. Herencia con métodos públicos y protegidos.

B usa a A, entonces las clases deben de permanecer unidas en un mismo servicio Web. Ver la Figura 7.

Figura 7. Servicio Web C.

3) Atributos y métodos Friendly

A diferencia de otros lenguajes, en Java, cuando no se especifica la visibilidad de los datos estos se declaran por defecto friendly, lo que significa que son accesibles por todos los objetos dentro del mismo paquete. Ver la Figura 8.

public float Multiplicar(){ return x*y;}

Figura 8. Herencia de clases con métodos y atributos friendly.

43

Capítulo 4. Análisis de escenarios B usa a A, entonces las clases deben de permanecer unidas en un mismo servicio Web, siempre y cuando la clase derivada pertenezca al mismo paquete que la clase base. Ver la Figura 9.


Comúnmente, los métodos en una clase son públicos, por lo tanto es necesario localizar las clases externas que solicitan servicios unas de otras, para generar los racimos de clases que formen un servicio. Por otro lado comúnmente los datos de una clase son privados o protegidos, por lo que no es necesario localizar las clases externas que soliciten sus servicios. En una clase pueden existir atributos y métodos con diferentes modificadores de accesos, es decir, pueden existir atributos y métodos: privados, públicos, protegidos, friendly o una combinación de ellos. Para las relaciones de herencia es necesario que si en la clase base se encuentra al menos un método o atributo con el modificador de acceso público, las clases derivadas permanezcan unidas a ella, así como también es necesario localizar las clases externas que soliciten sus servicio o a las que ella los solicite, para que juntas formen un racimo de clases con el que se genere un servicio Web. De igual forma si en la clase base se encuentra al menos un método o atributo protegido, es necesario que las clases derivadas permanezcan unidas a su clase base. En caso de que en la clase base se encuentre al menos un atributo o método friendly, es necesario que las clases derivadas permanezcan unidas a ella, así como también es necesario localizar las clases dentro del mismo paquete que soliciten sus servicios o a las que ella los solicite para que juntas formen un racimo de clases con el que se genere un servicio Web. 4) Llamada al constructor de la clase padre con un Super Los constructores no se heredan, sin embargo se pueden invocar con la instrucción super, como en el ejemplo de la Figura 10. Lo que genera una dependencia entre la clase derivada que invoca al constructor de la clase base. La instrucción super también es utilizada para invocar otros métodos de la clase padre, no sólo al constructor.

44


Figura 10. Clase A, ejemplo de llamada al constructor de la clase padre con un super.

B usa a A, entonces ambas clases deben de permanecer unidas en un mismo servicio. 5) Clases abstractas y métodos abstractos. En una clase abstracta puede haber métodos abstractos o métodos no abstractos. Ver la Figura 11.

class A { ... A(int ix, int iy){ ... }; } class B extends A { ... B(int ix, int iy) { super(ix, iy); z= 0; } }

La claclase derivada Conve

public abstract class Graphics { public abstract void drawLine( int x1,int y1,int x2,int y2 ); } public class MiClase extends Graphics { public void drawLine( int x1,int y1,int x2,int y2 ) {

<código para pintar líneas -específico de la arquitectura-> }

}

Figura 11. Clase Graphics, ejemplo de clases abstractas y métodos abstractos.

se abstracta Graphics sólo contiene métodos abstractos que son sobrescritos en la MiClase, por lo que las alternativas a seguir pueden ser:

rtir cada clase en un servicio independiente. Ver la Figura 12.

Figura 12. Servicios Web Graphics y MiClase.

45

Capítulo 4. Análisis de escenarios Sólo dejar el servicio MiClase. Ver la Figura 13.

Figura 13. Servicio Web MiClase.

abstract class GraphObj { int x, y; GraphObj(int ix, int iy) { x= ix; y= iy; } void Move(int dx, int dy) { x+= dx; y+= dy; } abstract void Paint(Graphics g); } class Line extends GraphObj { int ix, iy; Line(int aix, int aiy, int afx, int afy) { super((aix+afx)/2, (aiy+afy)/2); ix= aix; iy= aiy; } void Paint(Graphics g) { g.DrawLine(xi,yi,x+(x-xi),y+(y-yi)); } }

Figura 14. Clase GraphObj.

La clase GraphObj es una clase abstracta que contiene tanto métodos abstractos como métodos no abstractos. Lo que quiere decir que las clases deben permanecer unidas como un único servicio. Ver la Figura 15.

Figura 15. Servicio Web GraphObject.

46

Capítulo 4. Análisis de escenarios 6) Interfaces En Java una interfaz es una implementación completamente abstracta. Para indicar que una clase implementa una interfaz, se utiliza la palabra reservada implements. Ver la Figura 16.

Figura 16. Clase VideoClip, ejemplo de interfaz.

public interface VideoClip { void play(); void bucle(); void stop(); } class MiClase implements VideoClip { void play() { <código> } void bucle() { <código> } void stop() { <código> } }

Como la interfaz no encapsula datos, ni contiene código, no hay una herencia de implementación, ni de datos, solamente se heredan los métodos, por lo tanto no es necesario que la clase derivada permanezca unida a la clase base en un mismo servicio Web. Ver la Figura 17.

Figura 17. Servicio Web MiClase.

4.2.1.2. Escenario 2. Relaciones de asociación y agregación En ocasiones en la programación orienta a objetos interesa crear objetos que se compongan de otros objetos, para lograrlo se recurre a las relaciones de asociación y agregación entre clases. 1) Relaciones de asociación. Una relación se considera de asociación cuando se declara un objeto local a una función o cuando la función recibe como parámetro a un objeto. Ver la Figura 18.

47


class A {…} class B { public void function () { private A a; } }

Figura 18. Clase A, ejemplo de relación de asociación. La clase B tiene una relación de asociación a la clase A, en este caso se puede optar por dos alternativas: a) Sustituir las relaciones de agregación por mecanismos de integración de aplicaciones. Ver la Figura 19.

Figura 19. Integración de aplicaciones entre el servicio A y B.

b) Dejar los dos servicios de forma independientes. Ver la Figura 20.

Figura 20. Servicios Web A y B.

2) Relaciones de agregación. La agregación es un caso especial de asociación. Se considera una relación de agregación cuando el objeto se declara en la definición de la clase. Las relaciones de agregación pueden ser de dos tipos, fuertes o débiles. 2.1) Relación de agregación débil. Son aquellas clases cuya existencia no depende de la existencia de otras clases, ver la Figura 21 y Figura 22. En las relaciones de agregación débiles se declara el objeto en la definición de la clase, pero éste no se instancía.

48

Capítulo 4. Análisis de escenarios class A

{...} class B { private A a; }

Figura 21. Clase A, ejemplo de relación de agregación débil.

BA

Figura 22. Relación de agregación débil.

Las opciones disponibles para este caso son las mismas que para las relaciones de asociación. 2.2) Relación de agregación fuerte. También llamada composición. En las relaciones de agregación fuertes se declara e instancía el objeto en la definición de la clase. Ver la Figura 23 y Figura 24.

class A { ... } class B { private A a = new A(); }

Figura 23. Clase A, ejemplo de relación de agregación fuerte.

B A

Figura 24. Relación de composición.

La relación de composición es una relación fuerte, por lo que las clases deben de mantener su colaboración, ya sea por mecanismos de integración de aplicaciones como se muestra en la Figura 25 ó manteniendo las clases unidas en un mismo servicio, como se muestra en la Figura 26.

49


Figura 25. Integración de aplicaciones entre A y B.


En el escenario número 2 de relaciones de agregación y asociación número inciso 4.2.1.2, surge una pregunta importante: ¿Qué sucederá con los servicios, que para dar alguna funcionalidad sea indispensable su integración con otros servicios? En este caso es importante resaltar que será necesario especificar en las precondiciones del servicio, con cuáles servicios Web es necesario que se componga para otorgar su funcionamiento. La relación de agregación es una relación fuerte, por lo que las clases deben de mantener su colaboración, ya sea por mecanismos de integración de servicios o manteniendo las clases unidas. 4) Relación de composición a la clase base. Ver la Figura 27.

B

A

obj

Figura 27. Relación de composición a la clase base.

Si existe una relación de composición a la clase base significa que se requiere la colaboración de una de sus clases derivadas, incluso de sí misma. Por lo que se necesita que permanezcan unidas la base con las clases derivadas en las que el objeto “obj” tome la forma o el tipo. Ver la Figura 28.

50



4.2.1.3. Escenario 3. Patrón de diseño Strategy. Ver la Figura 29.

Figura

area()

Cuadrolado : Long

area()

Circuloradio : Long

area()

Figura 29. Patrón de diseño Strategy.

Figura 30. Ejemplo del patrón de diseño Strategy.

public interface Figura { public long area( ); } public class Círculo implements Figura { private long radio; public Circulo( ); public long area( ); } public class Cuadrado implements Figura { private long lado; public Cuadrado( ); public long area( ); }

51


Figura 32. Servicio Web Figuras Geométricas.

El patrón de diseño Strategy en Java se implementa con una interfaz como clase base y una serie de clases derivadas que implementan a esa interfaz. La arquitectura resultante de la separación del patrón de diseño Strategy sería la siguiente: Escenario de éxito 1. La clase base de la arquitectura es una interfaz, por lo que no contiene la implementación de los métodos sino únicamente la definición de éstos, los cuales son implementados en las clases derivadas. Este escenario de éxito consiste en separar la clase base de sus clases derivadas para formar un servicio Web por cada clase derivada. Ver la Figura 31.

Figura 31. Servicios Web Cuadrado y Círculo. La ventaja de dicho escenario es que se pueden obtener un mayor número de servicios Web del que se tendrían si se mantiene la arquitectura completa. La desventaja es que se estarían separando una serie de clase que tienen cierta funcionalidad en común, por lo que tal vez para el usuario tendría un mayor beneficio si se mantiene la arquitectura completa como un servicio debido a que le proporcionaría mas funcionalidad que el desarrollado con una clase independiente. Escenario de éxito 2. También se puede mantener la arquitectura del patrón, dejando en un servicio la opción de formar cuadros o círculos. Ver la Figura 32.

52

Capítulo 4. Análisis de escenarios Escenario de éxito 3. Otra alternativa es mantener a cada una de las clases derivadas unidas a su clase base. Ver la Figura 33.

Figura 33. Servicios Web Cuadrado y Círculo. Esta alternativa es poco viable debido a que como se mencionó anteriormente la clase base es una interfaz que no contiene implementación, por lo que el mantenerla unida a la clase derivada no aumenta el cuerpo del servicio pero no su funcionalidad.

4.2.1.4. Patrón de diseño Composite.

Cuando las clases derivadas tienen una relación de agregación hacia la clase base implementando el patrón de diseño Composite como se muestra en la Figura 34 y la Figura 35, significa que requiere el uso de una o más de una clase dentro de la misma jerarquía, incluso de sí misma. Por ejemplo:

Figura 34. Diagrama de clases de los cálculos de regresión y correlación.

cRegL1n2

cRegL1n2()Calcula()

cRegPar2

cRegPar2()Calcula()

cCorrL1n2coef : Double

cCorrL1n2()Calcula()getCoef()setCoef()

cCorrPar2Coef : Double

cCorrPar2()Calcula()getCoef()serCoef()

cAlgor2L1

cAlgor2L1()AlgoritmoInterfaz()Calcula()

53


Figura 36. Servicio Web Regresión y Correlación.

Escenario de éxito 2.

tra alternativa es eliminar la clase abstracta, separar las clases, convertirlas a servicios Web y

class cCorrPar2 extends cAlgor2L1 { private double coef; private cAlgor2L1 obj = new RegPar2(); public cCorrPar2(); public void Calcula(); public double GetCoef(); public void SetCoef(double dato); }

Figura 35. Clase cCorrPar2, ejemplo del patrón de diseño Composite. La clase cCorLin2L1 tiene una relación de agregación hacia la clase base cAlgor2L1. La clase con la que requiere colaborar específicamente se puede observar en el código de la misma, en este caso la clase cCorrPar2 requiere de la clase RegPar2. Escenario de éxito 1. Una alternativa es mantener la arquitectura del marco como un único servicio. Ver la Figura 36.

Opor último relacionar por mecanismos de integración los servicios que requieren colaborar. Ver la Figura 37.

54


scenario de éxito 3.

tra alternativa más es mantener unidas las clases que están relacionadas. Ver la Figura 38.

4.3. ¿Qué opción se apegaría más a los p ectura Orientada a

os principios de la Arquitectura Orientada a Servicios se describen en el capítulo 2.

Las cuatro alternativas propuestas en la sección 4.2 cumplen con los principios de la

Figura 37. Servicios Web de Regresión y Correlación.

E O

Figura 38. Servicios Web de Regresión y Correlación. rincipios de una Arquit

Servicios? L SOA, salvo una excepción, la alternativa 3 de sustituir las relaciones de agregación por mecanismos de integración de aplicaciones no cumple con el sexto principio, el cual dice que “Los servicios Web deben de tener bajo acoplamiento” y por consiguiente con el primero que dice que “Los servicios Web deben ser reusables”. Los servicios resultantes en esta solución tendrían un alto grado de acoplamiento, debido a que sin la colaboración de otros servicios con los que originalmente tenían relaciones de agregación o con servicios similares a estos, no podrían proporcionar funcionalidad alguna.

55

Capítulo 5. Procedimiento para la obtención de MSW’s a partir de MOO’s

Capítulo 5) PROCEDIMIENTO PARA LA OBTENCIÓN DE MSW’s A PARTIR DE MOO’s

En este capítulo se describe el procedimiento desarrollado para dar solución al problema planteado en este proyecto de tesis, el cual se explica a detalle en el capítulo 2. Un procedimiento se define como“Una serie de pasos claramente definidos, que permiten trabajar correctamente” [42]. En el contexto de este proyecto de tesis podemos definir procedimiento como los pasos requeridos para cumplir con el objetivo de migrar MOO’s a MSW’s. En la Figura 39 se ilustran las cuatro etapas del procedimiento desarrollado en esta tesis. En el que se especifica que la precondición para iniciar el procedimiento es contar con el código del MOO y cuya poscondición es la generación de los servicios Web del marco.

56


Análisis del MOO

Separación del MOO

Generación de servicios Web

Integración de servicios Web

Código original del MOO

BD

Servicios Web

Figura 39. Procedimiento para la obtención de MSW a partir de MOO. Las fases de la Figura 39 se describen de la siguiente manera:

1. Análisis del MOO. Para lograr un proceso de transformación adecuado es necesario identificar y entender las diferentes relaciones y dependencias que se presentan entre las entidades de software que integran al MOO. El principal objetivo de esta fase es formar una base de datos con la información adquirida a partir del código original.

2. Separación del Marco. En este paso se aplican los métodos heurísticos de los

escenarios de éxito analizados y expuestos en el capítulo 3. Con la base de datos obtenida en la fase de análisis y con ayuda de los escenarios mencionados, se lleva a cabo la separación de las clases que requieren colaborar como servicios Web, identificando racimos o grupos de clases (a los cuales llamaremos componentes en lo sucesivo) que asociadas formarán cada servicio Web.

3. Generación de servicios Web. Una vez identificados los componentes, el siguiente

paso es hacer su conversión a servicios Web. En este paso se presenta el método para realizar esta tarea de forma semi-automática.

57


4. Integración de servicios Web. Esta etapa consiste en sustituir las relaciones de agregación originales en el marco por mecanismos de integración de servicios Web.

5.1. Análisis del MOO En un MOO existen relaciones entre sus clases, formando dependencias que repercuten en la toma de decisiones para la formación de servicios Web. Para identificar estas relaciones es necesario analizar el código fuente y extraer información de sus elementos tales como: clases, métodos y atributos. Esta fase es muy importante en el procedimiento debido a que a partir de la información obtenida en ella es posible desarrollar la fase de separación, generar los servicios Web e implementar la integración de aplicaciones. La forma en que se refleja la información en la base de datos se indica con un (*). Primero se identifican las características básicas de una clase como son el tipo de la clase y su firma.

*T_Clase = 1. Indica que se trata de una clase base. *Firma = private, public, abstract. Firma de la clase.

Las dependencias que se identifican son las siguientes: 5.1.1. Relaciones de Herencia (extends) Las dependencias identificadas en las relaciones de herencia se muestran en la Tabla 4.

Tabla 4. Dependencias identificadas en las relaciones de herencia Dependencia Representación en

la base de tatos Interpretación

*T_Clase = 2 Indica que es una clase derivada. *HI = “nombre de

la clase” Indica el nombre de la clase que hereda.

Datos públicos o protegidos en la clase base (public y protected)

*T_Método = 1 Con un método de la clase que sea public o protected se guarda un uno.

Métodos públicos o protegidos en la clase base (public y protected)

*T_Atributo = 1 Con un atributo que sea public o protected se guarda un uno.

Llamadas al constructor de la clase padre (super)

*Super = 1 Indica que hay una llamada al constructor de la clase padre.

Interfaces (interface) *Interface = 1 Indica que la clase es una interface.

Implementaciones (implements) *T_Clase = 3 Indica que es una clase derivada

58


de una interfaz. *HI = “nombre de la clase”

Indica el nombre de la interfaz a la que implementa esta clase.

Clases abstractas (abstract) *Firma = abstract 5.1.2. Relaciones de Agregación

*Agregación = 1. Indica que existe al menos una relación de agregación *Agregada = “nombre de la clase”. Indica el nombre de la clase a la que agrega. 5.2. Separación del Marco En esta fase se realiza una serie de consultas a la base de datos que generan como respuesta el nombre de las clases que están relacionadas por mecanismos de herencia y aquellas que se relacionan por mecanismos de agregación. El primer paso es ubicar las clases en directorios para facilitar al usuario el manejo del marco: • Identificar las clases que son de tipo base, es decir aquellas cuyo valor del campo T_Clase

en la base de datos es igual a uno. Crear un directorio por cada clase encontrada, guardando dentro una copia de la clase.

• Se identifican las clases que son derivadas, es decir, aquellas cuyo valor del campo

T_Clase en la base de datos es igual a dos, y se coloca una copia en el directorio en el que se ubica su clase padre.

• Se identifican las clases de tipo interface, es decir, aquellas cuyo valor del campo interface

en la base de datos es igual a uno. Se crea un directorio por cada clase interfaz encontrada, guardando dentro de éste una copia.

El siguiente paso es presentar al usuario una tabla como la que se muestra en la Tabla 5, en la que se muestran las relaciones de herencia almacenadas en la base de datos, con el objetivo de que conozca la información que le será útil en la siguiente etapa.

Tabla 5. Relaciones de herencia

Nombre del Archivo Nombre de la clase

Clase base de la que es derivada

5.3. Generación de Servicios Web Una vez que se ha analizado el código del MOO extrayendo información sobre la estructura del código original y que además han identificado y separaron los componentes que van a ser convertidos a servicios Web, el siguiente paso es convertir esos componentes a servicios Web.

59

Capítulo 5. Procedimiento para la obtención de MSW’s a partir de MOO’s El objetivo de esta fase es crear servicios Web tomando en cuenta las siguientes restricciones: 1. No es posible convertir a servicio Web una clase que contenga la palabra reservada extend, es decir, todas aquellas clases que son derivadas. Para llevar este tipo de clases a servicios Web, es necesario generar una interfaz en la cual se declaren todos los métodos tanto de la clases base, como de las clases derivadas.

Por ejemplo, ver las Figuras 40, 41 y 42:

Figura 40. Diagrama de clases del MOO Figuras Geométricas.

Figura

Circulo Rectángulo Triangulo

Figura 41. Clase Figura del MOO Figuras Geométricas.

Figura 42. Clase Circulo del MOO Figuras Geométricas.

public abstract class Figura { protected int x; protected int y; public Figura(int x, int y) { this.x=x; this.y=y; } public abstract double area(); }

class Circulo extends Figura{ protected double radio; public Circulo(int x, int y, double radio){ super(x,y); this.radio=radio; } public double area(){ return Math.PI*radio*radio; …..

Se tienen cuatro clases:

• La clase base Figura: contiene un constructor y un método abstracto area el cual se implementa en las clases derivadas.

60


• Las clases concretas Circulo, Rectangulo y Triangulo: contienen un constructor e implementan el método abstracto area.

Para generar un servicio Web con estas clases se crea la siguiente interfaz, ver la Figura 43:

class FiguraGeometrica{ public double Circulo(int x, int y, double radio){ double resultado; Figura fig = new Circulo(x,y,radio); resultado = fig.area(); return resultado; } public Rectangulo(int x, int y, double ancho, double alto){ double resultado; Figura fig = new Rectangulo(x, y, ancho, alto); resultado = fig.area(); return resultado; } public Triangulo(int x, int y, double base, double altura){ double resultado; Figura fig = new Triangulo(x, y, base, altura); resultado = fig.area(); return resultado; } }

Figura 43. Clase FiguraGeometrica. En esta interfaz:

• Se declaran los métodos tanto de la clase base (si existen) como los de las clases derivadas.

• Se crea una relación de asociación a la clase base. • Se le da la forma de la clase derivada o la clase base según sea el caso. • Se invoca al método especificado, tomando en cuenta si se espera o no un valor de

retorno.

Para este caso específico se crea la clase FiguraGeometrica, en ella se declaran los métodos: Circulo, Rectangulo y Triangulo. Para cada método dentro de la clase se crea una variable de tipo Figura, se le da la forma de la clase derivada con los parámetros del constructor. Por último se invoca al método area, guardando el valor de retorno en la variable resultado. 2. Sólo se aceptan métodos Web que reciban parámetros de tipo primitivo. Los servicios Web están diseñados principalmente para trabajar con atributos primitivos que sean conocidos por todos los usuarios de los servicios. Por lo que para generar servicios Web

61

Capítulo 5. Procedimiento para la obtención de MSW’s a partir de MOO’s que manejen datos de referencia como se muestra en el siguiente ejemplo se requiere buscar alternativas que permitan cumplir con esta restricción.

Figura 44. Clase cSumatoria.

En la clase cSumatoria el método Calcular recibe como parámetros de entrada un atributo primitivo (int) y un atributo de referencia Lista l1. Para cumplir con esta restricción se presentan dos alternativas:

1) Una alternativa práctica consiste en sustituir en los métodos del servicio Web los parámetros de entrada de tipo Lista por algún dato de tipo primitivo aceptado por el servidor, en el cual se pueda guardar temporalmente la información del parámetro para posteriormente pasar los valores de éste a el objeto de tipo Lista para su manejo interno en el servicio. Ver la Figura 45.

public class cSumatoria extends aCalculoAritmetico{ private float sumatoria; public float Calcular( Lista l1, int valor) { } }

public class ServicioCalculoAritmetico{ public ServicioCalculoAritmetico(){ } public float Sumatoria(float[] x, float[]y, int valor) { Lista l= new Lista(null, null); for (int i = 0; i < x.Length; i++) { ED Edatos1 = new ED((float)x[i], (float)y[i]); Elemento E1 = new Elemento(Edatos1, null, null); l.Agrega(E1); } aCalculoAritmetico aca = new cSumatoria(); return aca.Calcular(l, valor); } }

Figura 45. Clase ServicioCalculoAritmetico. En este caso se sustituye el objeto de tipo Lista por dos arreglos de flotantes debido a que la Lista guarda dos datos de tipo flotante por cada elemento.

62


<wsdl:message name="SumatoriaRequest">wsdl:part ="in0" ="impl:ArrayOf_xsd_float" /> name typewsdl:part ="in1" ="impl:ArrayOf_xsd_float" /> name typewsdl:part ="in2" ="xsd:int" /> name type</ >wsdl:message

Figura 46. Fragmento del documento WSDL del servicio Web ServicioCalculoAritmetico.

Esta restricción se soluciona de esta manera, sin embargo, primero la información debe ser almacenada como datos de tipo primitivo, lo que puede generar algunos inconvenientes. Por ejemplo, si tenemos la siguiente clase, ver la Figura 47.

Figura 47. Clase Datos.

Y tenemos un servicio Web que en uno de sus métodos reciba un objeto de tipo Datos. Con esta alternativa el método Web quedaría de la siguiente manera, ver la Figura 48.

Figura 48. Ejemplo de método Web.

public class Datos { public int a; public String b; public char c; public float d; public double x; }

metodoWeb( int a, String b, char c, flota d, double x ) { Datos d = new Datos; d.a = a; d.b = a; d.c = c; d.d = d; d.x = x; }

Entre más complejo sea el objeto, los parámetros de entrada del método Web serán cada vez más largos y el código para pasar los valores al objeto será más laborioso. Además por cada ocasión en que se modifique la clase Datos, se tendrá que modificar el servicio que la implemente para recibir y guardar nuevos parámetros.

2) La solución anterior es la más práctica, sin embargo los objetos pueden ser tan complejos que incluyan múltiples atributos de diferentes tipos, complicando la tarea de encontrar su equivalencia en datos primitivos. Por lo que la solución menos práctica pero más genérica es la serialización de objetos, debido a que permite obtener el objeto completo en su equivalente a un arreglo de bytes y posteriormente obtener de nuevo a partir de ese arreglo el objeto original en un par de instrucciones sin importar lo complejo que éste sea.

63

Capítulo 5. Procedimiento para la obtención de MSW’s a partir de MOO’s Para poder serializar un objeto hay que declarar el objeto como serializable. Por ejemplo en la Figura 49 se presenta la declaración de un objeto serializable.

Figura 49. Declaración de un objeto serializable. El objeto Lista ya es serializable, el siguiente paso es escribir la clase que se va a encargar de la serialziación. Existen dos flujos de datos ObjectInputStream y ObjectOutputStream que están especializados en la lectura y escritura de objetos, como se muestra en la Figura 50.

Figura 50. Clase SerializarLista.

import java.io.Serializable; public class Lista implements Serializable //implementa Serializable {

import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.IOException; import java.io.ObjectInputStream; import java.io.ObjectOutputStream; public class SerializarLista{ byte [] writeObject(java.io.ObjectOutputStream stream, Lista L1) throws IOException { ByteArrayOutputStream bs= new ByteArrayOutputStream();//Crea flujo de bytes de salida ObjectOutputStream os = new ObjectOutputStream (bs); os.writeObject(L1); //Escribe objetos al flujo de salida. byte[] bytes = bs.toByteArray(); //Convierte el flujo de salida a un arreglo de bytes. os.close(); //Se cierra el flujo. return bytes; //Retorna el objeto serializado. }

El método para serializar se presenta a continuación:

a) Se requiere un objeto de tipo Lista: Lista L1

b) Creamos un flujo de bytes de salida a un arreglo: ByteArrayOutputStream bs= new ByteArrayOutputStream()

c) El flujo de salida ObjectOutputStream es el que procesa los datos y se debe vincular a

un objeto ByteArrayOutputStream: ObjectOutputStream os = new ObjectOutputStream (bs)

64


d) El método writeObject escribe los objetos al flujo de salida: os.writeObject(L1) e) Finalmente, se cierran los flujos: os.close()

Es necesario respetar exactamente tanto la asignatura del método como la primera acción a realizar. Así como existe un método que serializa debe existir un método que realiza la inversa y recupere el objeto serializado. Ver la Figura 51.

El méto

a) b)

c)

d)

procede clases convier

public Lista leerobjeto(byte[] b) throws IOException, ClassNotFoundException{ ByteArrayInputStream bs= new ByteArrayInputStream(b); ObjectInputStream is = new ObjectInputStream(bs); Lista d = (Lista)is.readObject(); is.close(); return d; }

Figura 51. Método para deserializar el objeto Lista.

do para deserializar se presenta a continuación:

Se crea un flujo de bytes de entrada a un arreglo: ByteArrayOutputStream bs= new ByteArrayOutputStream()

El flujo de entrada ObjectInOutputStream es el que procesa los datos y se ha de vincular a un objeto ByteArrayInputStream: ObjectOutputStream os = new ObjectOutputStream (bs)

El método readObject lee los objetos del flujo de bytes de entrada, en el mismo orden en el que han sido escritos: Lista d = (Lista)is.readObject()

Se cierran los flujos: is.close();

Una vez que se tiene la clase que serializará la Lista y la clase que la deserializa se a generar el servicio Web.

Para los casos en los que no se presentan dependencias, como son las interfaces y las que implementan a la interfaz. La interfaz se elimina y sus clases derivadas se ten en servicios Web de forma independiente.

65

Capítulo 5. Procedimiento para la obtención de MSW’s a partir de MOO’s El método de transformación a servicios de las clases que implementan interfaces es el siguiente:

a) Identificar en la base de datos las clases de tipo implements, aquellas cuyo valor en el campo T_Clase sea igual a tres.

b) Hacer una copia de cada una de las clases al directorio de clases del servidor Tomcat, C:\apache-tomcat-5.5.17\webapps\axis\WEB-INF\classes.

c) Compilar las clases. Javac *.java. d) Generar un archivo de despliegue WSDD (por sus siglas en inglés Web Service

Deployment Descriptor) para cada una de las clases y guardarlo en el directorio axis. C:\apache-tomcat-5.5.17\webapps\axis\. Los archivos WSDD tienen el formato que se presenta en la Figura 52.

Figura 52. Ejemplo del documento WSDD del servicio Web HolaMundo.

<deployment xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"> <service name="HolaMundo" provider="java:RPC"> <parameter name="className" value="HolaMundo"/> <parameter name="allowedMethods" value="*"/> </service> </deployment>

e) Ejecutar el comando java org.apache.axis.client.AdminClient *.wsdd para cada

documento WSDD generado. f) Para verificar que los servicios fueron generados y desplegados de forma correcta, se

invoca la siguiente página en el navegador: http://localhost:8080/axis/servlet/AxisServlet.

Cabe mencionar que ninguna de las dos restricciones se resuelve de forma automática por la herramienta MOO2MWS presentada en el capítulo 6, de tal forma que cuando se presenten estos casos el usuario debe de seguir manualmente los pasos mencionados en las restricciones 1 y 2. 5.4. Integración de Aplicaciones de Servicios Web Hasta este punto del capítulo 5, ya se especificó cómo tratar las relaciones de herencia y las interfaces. El último punto es especificar cómo tratar las relaciones de asociación. Las relaciones de asociación en un marco orientado a objeto permiten las llamadas entre clases. Cuando las clases se convierten en servicios tienen que seguir colaborando pero ya no a nivel de clases sino a nivel de servicios.

66

Capítulo 5. Procedimiento para la obtención de MSW’s a partir de MOO’s Por lo que de forma interna un servicio llama a otro, obteniendo un resultado esperado, formando lo que se conoce como integración de aplicaciones. Para ilustrar este punto se muestra el siguiente ejemplo, ver la Figura 53. public class Calculadora {

public int sumar(int x, int y) { return x + y; } public int restar(int x, int y) { return x - y; } }

public class Calcular { public int resultado(){ int resultado; int x = 30; int y = 30; Calculadora calc = new Calculadora(); resultado = calc.sumar(x,y); return resultado; } }

Figura 53. Ejemplo de la fase de integración de aplicaciones del procedimiento. La clase Calcular tiene una relación de asociación a la clase componente Calculadora. La clase Calculadora puede trabajar de forma independiente como un servicio ya que no requiere de la clase Calcular, mientras que la clase Calcular necesita seguir manteniendo una relación con la clase Calculadora. Para lograr mantener una relación entre los servicios Web Calcular y Calculadora desarrollados a partir de las clases Calcular y Calculadora es necesario utilizar la integración de aplicaciones. Para lograr este proceso se debe modificar la clase Calcular, convirtiéndose internamente como un cliente del servicio Web Calculadora en el que realice la conexión al servicio e invoque los métodos Web que requiera como se muestra en el siguiente código de la Figura 54. Por último una vez que se modificó la clase, se convierte en servicio Web, generando el servicio Web Calcular que se encuentra integrado al servicio Web Calculadora y termina el proceso.

67


import org.apache.axis.client.Call; import org.apache.axis.client.Service; import org.apache.axis.encoding.XMLType; import javax.xml.rpc.ParameterMode; public class Calcular { public int cliente() throws Exception { String endpoint = "http://localhost:8080/axis/Calculadora.jws"; String method = "sumar"; Integer i1 = new Integer(30); Integer i2 = new Integer(30); Service service = new Service(); Call call = (Call)service.createCall(); call.setTargetEndpointAddress( new java.net.URL(endpoint) ); call.setOperationName( method ); call.addParameter( "op1", XMLType.XSD_INT, ParameterMode.IN ); call.addParameter( "op2", XMLType.XSD_INT, ParameterMode.IN ); call.setReturnType( XMLType.XSD_INT ); Integer ret = (Integer) call.invoke( new Object [] { i1, i2 }); return ret; } }

Figura 54. Clase Calcular, ejemplo de la fase de integración de aplicaciones del procedimiento. Las dos clases son convertidas a servicio, pero dentro de la clase Calcular se cambia la relación de agregación original, por las relaciones de integración de aplicaciones al servicio Web Calculadora. Ver la Figura 54. Para que un servicio sea una integración de aplicación a otro servicio se tiene que especificar: • El URL del servicio al que invoca. • El método al que se invoca. • Los valores de entrada se especifican creando objetos de tipo primitivo, por ejemplo el tipo

int tiene el objeto Integer. • Los valores de retorno. De esta forma se elimina el problema de comunicación entre clases, sustituyendo las relaciones de agregación por mecanismos de integración de servicios Web. Sin embargo no para todos los casos resulta eficiente desarrollar el proceso de integración de aplicaciones como se puede ver en el siguiente ejemplo. Ver la Figura 55.

68


Elemento E; ED Aux; for (i = 0; i < l.numElementos() - 1; i++) { E = l._GetH(); for (j = 0; j < l.numElementos() - i - 1; j++) { if (((E._GetNext().GetED()._GetVal1() < E.GetED()._GetVal1()) && tipo == true) || ((tipo == false && (E._GetNext().GetED()._GetVal1() > E.GetED()._GetVal1())))) { Aux = E._GetNext().GetED(); E._GetNext()._SetED(E.GetED()); E._SetED(Aux); } E = l._Proximo(E); } }

Figura 55. Ejemplo de problema de múltiples llamadas entre servicios. Analizando visualmente el código de las clases se puede ver que el acceso a Elemento y ED se encuentra dentro de un ciclo, de tal manera que si se invoca a Elemento y ED como servicios Web y no como clases, se estaría haciendo una petición a los servicios varias veces por cada elemento contenido en la Lista, lo cual afecta de manera considerable el rendimiento en cuanto al tiempo de respuesta de cada servicio e incrementa el consumo de red. En estos casos es mejor dejar el manejo interno de las clases sin integración de aplicaciones a los servicios Lista, Elemento y ED. Es decir, dejar las clases Lista, Elemento y ED, contenidas en el servidor de servicios Web para que las clases puedan acceder a ellas de manera interna como clases y no como servicios. Cabe mencionar que dicha decisión la toma el usuario después de haber analizado visualmente el código de los métodos del marco.

69

Capítulo 6. Implementación de prototipo

Capítulo 6) IMPLEMENTACIÓN DE PROTOTIPO

6.1. Análisis del Sistema En este capítulo se presenta la parte principal del documento de análisis de requerimientos y diseño del prototipo MOO2MSW, modelados con diagramas de casos de uso, de secuencia y de actividad del lenguaje de modelado unificado UML. La definición de escenarios y los diagramas de actividad se encuentra en el anexo A. En la Figura 56 se muestra el diagrama de casos de uso general de la herramienta, mostrando las opciones que se le presentan al usuario. Cada caso de uso representa un módulo de la herramienta. Son tres los casos de uso principales: Analizar código, Separar el MOO y Generar Servicios Web. Los actores son: Usuario, la persona que usa la herramienta; Archivo(s) Fuente: archivos que contienen el código original del marco, que el usuario escoge para

70

Capítulo 6. Implementación de prototipo generar los servicios Web, y Base de Datos, es la base de datos diseñada para almacenar la información resultante del análisis sintáctico.

Usuario

CU-1. Analizar código

CU-3. Generar Servicios Web

CU-2. Separar el MOO Base de Datos

Archivo(s) Fuente

Figura 56. Diagrama general de casos de uso. En la Figura 57 se muestra el diagrama del caso de uso Analizar código, el cual corresponde a la fase de análisis del procedimiento y al módulo de análisis del sistema. El módulo de análisis del sistema es requerido para realizar un análisis sintáctico de cada una de las clases que forman al MOO, con el objetivo de obtener la información de las características importantes de las entidades de software, tales como el nombre de la clase, las relaciones de herencia, agregación, entre otras. Los casos de uso requeridos para llevar a cabo el análisis sintáctico son: Analizar código, Identificar características de la(s) clase(s), Identificar relaciones de agregación y Almacenar información.

71


Figura 57. Diagrama del caso de uso Analizar código.

el código original del arco y posteriormente se almacena la información en la base de datos.

ión del MOO que se voca después del análisis sintáctico cuando se elige la opción Separar.

o de la clase padre y das las clases de tipo interfaz se guardan en un directorio de interfaces.

eparar el MOO, Separar las clases base, Separar las clases derivadas y Separar las interfaces.

Usuario

Archivo(s) Fuente

CU-1 Analizar códigoCU-1.1 Identificar caracteristicas

de la(s) clase(s)

<<include>>

Base de DatosCU-1-2 Almacenar información

<<extend>>

Primero se identifican las características de las clases a partir dm En la Figura 58 se muestra el diagrama del caso de uso separacin El módulo consiste en reubicar una copia de las clases originales del marco en directorios específicos. Por cada clase base se crea un directorio y se guarda una copia de la clase dentro de él. Las clases derivadas se guardan en el mismo directorito Los casos de uso requeridos para llevar a cabo la separación son: S

72


Usuario

Base de Datos

CU-2.1 Separar clases base

CU-2.2 Separar las clases derivadas

CU-2 Separar el MOO

<<include>>

<<include>>

CU-2.3 Separar las interfaces

<<include>>

Figura 58. Diagrama del caso de uso Separar el MOO.

Primero se separan las clases base, después las clases derivadas y por último las interfaces, para realizar esta separación se extrae cierta información de la base de datos. En la Figura 59 se muestra el diagrama del caso de uso Generar Servicio Web, que se invoca después de la separación cuando se elige la opción generar servicio Web. Este módulo consiste en hacer una copia de las clases y colocarlas en el directorio clases del servidor axis, compilarlas, crear un descriptor de despliegue wsdd propio de axis para cada servicio Web y por último invocar los descriptores de despliegue. Los casos de uso requeridos para llevar a cabo la generación de servicios son: Generar Servicios Web, Copiar clases, Compilar clases, Generar WSDD e Invocar WSDD.

73


74

Figura 59. Diagrama del caso de uso Generar Servicio Web.

Usuario

Base de DatosCU-3.1 Copiar clases

CU-3.2 Compilar clases

CU-3.3 Generar WSDD

CU-3 Generar servicios Web

CU-3.4 Invocar WSDD

<<include>>

<<include>>

<<include>>

<<include>>

Primero se copian las clases al directorio clases de axis y se compilan, posteriormente se genera el archivo de despliegue WSDD y por último se invoca el WSDD. 6.2. Diseño del Sistema

En la Figura 60 se muestra el diagrama general de clases de la herramienta. La arquitectura que presenta la herramienta esta formada básicamente por relaciones de agregación que se generan en la clase principal que corresponde a la interfaz en la cual se realizan las llamadas a las otras clases.


75

Figura 60. Diagrama de clases general del sistema.

jFrame

ActionListener

public void actionPerformed()

CleanBD

public CleanBD()public Connection()public void close()public void close()public void cleanBD()

JAVAFilter

public boolean accept()public String getDescription()private String getExtension()

JavaParser

JavaParser()public static void Inicializa()public static Connection getConnection()public static void DBClean()public static void close()public static void close()void main()

MAOO2MSW

public MAOO2MSW()public static void main()

MOO2MSW_jButton1_actionAdapter implements ActionListener

private MOO2MSW adaptee


MOO2MSW_jButton2_actionAdapterprivate MOO2MSW adaptee

MOO2MSW_jButton2_actionAdapter()public void actionPerformed()

Conexión

public Conexión()public int getlong()public int getlongbase()public int getlongherencia()public int getlonginterfase()public String[][] base interfase()public String [][] base()public String[][] Heredada()public String [][] Conectar()public Connection getConnection()public void close()public void close()

(from Use Case View)

Copiar

public Copiar()public void Copy()


Ejecutar

Ejecución()


MOO2MSW

private void jbInit()public void jButton1_actionPerformed()public void jButton2_actionPerformed()public void jButton3_actionPerformed()public void jButton4_actionPerformed()

obj obj obj

obj

obj

obj

WSDD

generawsdd()


Componente de IU

Componente de análisis

Componente de separación

Componente de generación de servicios Web

Capítulo 6. Implementación de prototipo En la Figura 61 se muestra el diagrama de clases que corresponde al módulo de análisis del sistema.

Componente de IU

jFrame(from Logical View)

CleanBD

public CleanBD()public Connection()public void close()public void close()public void cleanBD()

(from Logical View)

JAVAFilter

public boolean accept()public String getDescription()private String getExtension()JavaFilter()

(from Logical View)

JavaParser

JavaParser()public static void Inicializa()public static Connection getConnection()public static void DBClean()public static void close()public static void close()void main()analizar(String fichero)()execute()

(from Logical View)

ActionListener


(from Logical View)

MOO2MSW_jButton2_actionAdapter


MOO2MSW_jButton2_actionAdapter()public void actionPerformed()

(from Logical View)

MAOO2MSW

public MAOO2MSW()public static void main()

(from Logical View)MOO2MSW


(from Logical View)

cbdfc

jp

obj

MOO2MSW_jButton1_actionAdapter implements ActionListener



(from Logical View)

Componente IU

Figura 61. Diagrama de clases del módulo de análisis. Descripción de las clases: JFrame: Representación de una ventana con Swing. ActionListener: Es una interfaz del grupo de los “listeners” de la librería de Java, la cual tiene un único método: void actionPerformed (ActionEvent e). Se usa para detectar y manejar los eventos ActionEvents que tienen lugar cuando se produce una acción sobre un elemento del programa. MOO2MSW: Controla los atributos y eventos de la clase principal MOO2MSW. MOO2MSW: Clase que contiene los elementos Swing de la interfaz del sistema, la cual contiene relaciones de agregación con otras clases para invocar los diferentes métodos, en los eventos correspondientes. MOO2MSWjButton1_actionAdapter: Controla los eventos del componente jbutton1. MOO2MSWjButton2_actionAdapter: Controla los eventos del componente jbutton2. JavaFilter: Clase que funciona como filtro para que al abrir un diálogo de selección de archivos sólo se muestren aquellos archivos que sean de tipo Java.

76

Capítulo 6. Implementación de prototipo CleanBD: Clase encargada de establecer una conexión a la base de datos para eliminar los elementos contenidos en ella. Esta clase es utilizada para limpiar la base de datos cada vez que se va a analizar un nuevo MOO. JavaParser: Analizador sintáctico. Clase encargada de analizar sintácticamente a todas las clases que integran al MOO original, así como también de establecer una conexión con la base de datos para almacenar la información resultante. Para mostrar cómo funciona el módulo de análisis del sistema, en la Figura 62 se presenta el diagrama de secuencias que indica el flujo de mensajes principales entre las distintas clases de la aplicación.

Figura 62. Diagrama de secuencias del módulo de análisis.

:MOO2MSW :JAVAFilter CleanBD :JavaParser

fc= new JavaFilter()

fc

fc.addChoosableFileFilter()

jp= new JavaParser()

cbd= new CleanBD()

cbd

cbd.cleanBD()

jp

jp.analizar(fichero)Inicializa( )

getConnection()

execute( )

close( )

fc.showOpenDialog(this)

77

Capítulo 6. Implementación de prototipo La acción se inicia en la pantalla MOO2MSW cuando el usuario pulse el botón “Abrir”. El evento de este botón consiste en abrir un cuadro de diálogos para seleccionar archivos utilizando métodos y atributos del componente JFileChooser, una de las características de este componente, es que permite agregar filtros al cuadro de diálogos para especificar el tipo de archivo a mostrar. Se crea el objeto fc de tipo JAVAFilter para que sólo muestre archivos de tipo Java y se agrega al componente JFileChooser con el método addChoosableFileFilter(). La siguiente acción se inicia cuando el usuario pulsa el botón “Analizar”, lo cual indica que ya fueron seleccionados los archivos y el siguiente paso es iniciar el análisis sintáctico. Primero se crea el objeto cbd de la clase CleanBD para llamar al método cleanBD() encargado de limpiar la base de datos eliminando los registros de la base de datos. Posteriormente se crea el objeto jp de la clase JavaParser y se invoca el método analizar(String fichero) encargado de realizar el análisis sintáctico a cada clase del MOO. Dentro de la misma clase JavaParser se hacen llamadas a los métodos inicializar() para inicializar todas las variables dentro de la clase, getConnection() para establecer comunicación con la base de datos, execute() para realizar la inserción y por último close() para cerrar la conexión.

En la Figura 63 se muestra el diagrama de clases que corresponde al módulo de separación del sistema.


Conexión


MOO2MSW


(from Logical View)

con

Copiar

public Copiar()public void copy()

cp

Componente de IU

Figura 63. Diagrama de clases del módulo de separación.

78

Capítulo 6. Implementación de prototipo Descripción de las clases: Conexión: Clase encargada de realizar la conexión a la base de datos y extraer la información requerida para el proceso de separación. Copiar: Clase encargada de copiar archivos de un directorio a otro. Para mostrar cómo funciona el módulo de separación, en la Figura 64 se presenta el diagrama de secuencias, que indica el flujo de mensajes principales entre las distintas clases de la aplicación.

:MOO2MSW :Conexión :Copiarcon = new Conexión( )

con

tamaño = con.getlongbase()

nombre = con.base()

nombre[][]

directorio = new File(C:\interfases)

* directorio = new File(name)

* cop = new Copiar()

cop

*cop.copy(nombre1,nombre2)

tamaño = con.getlonginterfases()

nombreinterfase = con.baseinterfase()

*cop = new Copiar()

cop

*cop.copy(interfase1,interfase2)

tamaño = getlongherencia()

herencia = con.heredada()

herencia[][]

nombre[][]

*cop = new Copiar()

cop

*cop.copy(herencia1,herencia2)

(*) Indica que el proceso se encuentra dentro de un ciclo.

H

Figura 64. Diagrama de secuencias del módulo de separación.

79

Capítulo 6. Implementación de prototipo La acción se inicia en la pantalla MOO2MSW cuando el usuario pulsa el botón “Separar”, el evento de este botón crea el objeto con de tipo conexión utilizado para invocar al método getlongbase() que retorna el número de clases de tipo base existentes en la base de datos, después se invoca al método base() que retorna el nombre de las clases y su ubicación, se crea el directorio interfaz y se entra en un ciclo que consiste en crear un directorio por cada clase base encontrada, después se crea un objeto de tipo Copiar y se invoca al método copy() con el nombre del directorio origen y el nombre del directorio destino, concluyendo con el ciclo. La siguiente acción del evento es invocar al método getlonginterfaces() que retorna el número de clases de tipo interfaz, de igual forma se crea un ciclo para copiar todas las clases desde el archivo origen al directorio interfaz creado anteriormente. Por último se realiza el mismo proceso para las clases derivadas con la diferencia de que las copias no se guardan en un nuevo directorio con su nombre sino en el directorio de su clase base. En la Figura 65 se muestra el diagrama de clases que corresponde al módulo de generación de servicios Web del sistema.


Conexión


Copiar

public Copiar()public void copy()

Ejecutar

Ejecutar()ejecucion()

WSDD

generawsdd (String nombre)()WSDD()

MOO2MSW


(from Logical View)

con

cp ej

ws

Componente de IU

Figura 65. Diagrama de clases del módulo de generación de servicios Web.

Descripción de las clases: Ejecutar: Clase encargada de compilar clases. WSDD: Genera los archivos WSDD para los servicios Web.

80

Capítulo 6. Implementación de prototipo Para mostrar cómo funciona el módulo de separación, en la Figura 66 se presenta el diagrama de secuencia, que indica el flujo de mensajes principales entre las distintas clases de la aplicación.

Figura 66. Diagrama de secuencias del módulo de generación de servicios Web.

(*) Indica que el proceso se encuentra dentro de un ciclo.

La acción se inicia en la pantalla MOO2MSW cuando el usuario pulsa el botón “Generación de Servicios”, el evento de este botón crea el objeto con de tipo conexión utilizado para invocar al método getlong() que retorna el número de clases de tipo base y las clases que implementan las interfaces existentes en la base de datos. Después se invoca al método Conectar() que retorna el nombre de las clases y su ubicación, se inicia un ciclo, en el cual en cada iteración se crea un objeto Copiar, se invoca al método Copy() para copiar los archivos al directorio de clases del servidor axis. Al terminar el ciclo se crea el objeto Ejecutar ej y se invoca al método ejecución(). Este método compila todas las clases dentro del directorio. Se crea el objeto WSDD y se invoca al método generawsdd() con el nombre de la clase y se guardan los documentos WSDD resultantes en el directorio axis. 6.3. Análisis del Código Fuente Para realizar el análisis léxico y sintáctico del código original de las clases del MOO se emplea el generador de analizadores JavaCC, con una gramática para el lenguaje Java 1.4. Se realizó un estudio del analizador sintáctico de la gramática de Java desarrollado por Sriram Sankar [43] llamado “java1.4.jj”. Esta herramienta tiene asociadas las siguientes clases que son de ayuda para el análisis del código fuente.

81

Capítulo 6. Implementación de prototipo • ClassScope • Scope • SymtabManager Cuando se compila el archivo java1.4.jj se generan los siguientes archivos: • JavaParser.- Analizador generado. • JavaParserConstants.- Conjunto de constantes útiles. • JavaParserTokenManager.java.- Manejador de tokens (scanner ó analizador léxico). • JavaCharStream.- Describe una secuencia de caracteres que guarda la posición de las

líneas y columnas de los caracteres. • ParseException.- Lanza una excepción cuando se encuentran errores en el analizador. • Token.- Describe la secuencia de entrada de los tokens. • TokenMgrError.- Se encarga del manejo de errores presentados en los tokens. Se detectaron los puntos dentro de las reglas de la gramática en donde se introdujeron las acciones semánticas con el fin de obtener la información necesaria para llenar la base de datos que se emplea para realizar la separación de las clases y la generación de los servicios Web. El analizador generado se integró a la arquitectura del sistema para su uso interno. La información extraída por el analizador es ubicada en la base de datos. Las características detectadas por el analizador son: • Reconocimiento de la ubicación del directorio. • Nombre de las clases. • Tipo de la clase. • Herencia. • Interfaces. • Métodos públicos. • Atributos públicos. • Relaciones de agregación. • Implementaciones. • Clases base. Toda la información adquirida en esta etapa debe de ser almacenada para facilitar su uso posterior. Es por ello que se diseñó una Base de Datos en MySQL llamada bd la cual es representada por el diagrama Entidad-Relación de la Figura 67.

82


Figura 67. Modelo relacional de la base de datos.

Las tablas que conforman la base de datos son: Archivo: En esta tabla se almacena información referente al código de los archivos analizados. Nom_Clase: Nombre de las clases. Nom_Archivo: Nombre del archivo. Clases: En ella se almacena la información referente a las clases. Nom_Clase: Nombre de la clase. Firma: Modificador de acceso (publica, abstracta, privada, etc.). T_Metodo: En caso de que exista un método público, se almacena un 1. T_Clase: Clase base = 1, clase derivada = 2, una implementación = 3. T_Atributo: En caso de que exista un atributo público, se almacena un 1. Agregación: Si existe una relación de agregación se almacena un 1. Super: Si existe una llamada al constructor de la clase base se almacena un 1. HI: Nombre de la clase de la que se hereda o de la que se implementa. Interface: Si es de tipo interfaz, se almacena un 1. Agregación: En caso de que existe alguna relación de agregación, se almacenan los nombres de las clases componente. Nom_Clase: Nombre de la clase. Agregada: Nombre de la clase agregada. 6.4. Herramienta MOO2MSW (Marcos Orientados a Objetos hacia Marcos de Servicios Web) En la Figura 68 se muestra la interfaz de la herramienta MOO2MSW. Esta herramienta fue desarrollada para dar soporte al procedimiento y su objetivo es probar la factibilidad de que el procedimiento desarrollado es exitoso para los fines que se persiguen es esta tesis.

83

Capítulo 6. Implementación de prototipo La herramienta consta únicamente de una pantalla, la cual se encuentra dividida en 4 secciones que representan las fases del procedimiento. Y que la creación de una nueva interfaz para la jerarquía de herencia presentada en la fase de generación de servicios Web de la definición del procedimiento en el capítulo 5, no se realiza de forma automática, así como tampoco el proceso deserialización de la misma fase.

Figura 68. Pantalla principal de la herramienta MOO2MSW. En la primera sección de la herramienta “Fase 1. Análisis”, el usuario debe seleccionar las clases que integran al MOO a través del cuadro de diálogos “Abrir” el cual se muestra en la Figura 69. El cuadro de diálogos esta configurado para mostrar únicamente los archivos con extensión .java. El usuario debe seleccionar todos los archivos de un MOO y pulsar el botón “Abrir”. Automáticamente la herramienta muestra en el cuadro de texto de la Figura 70 los archivos que van a ser analizados.

84


Figura 69. Diálogo para abrir múltiples archivos.

Si se elige el botón “Cancelar” no se modifica la selección y se regresa a la pantalla principal.

Figura 70. Diálogo para mostrar los archivos a analizar.

Una vez seleccionados los archivos, el usuario debe elegir “Analizar” para que la herramienta realice el análisis y extraiga la información requerida de cada uno de los archivos con el analizador sintáctico, desarrollado e integrado al sistema. La sección dos de la herramienta “Fase.2 Separación” muestra los botones “Separar” y “Herencia”. El usuario debe seleccionar “Separar” para que el sistema realice

85


Figura 71. Sección “Fase Separación” del sistema.

ión tres del sistema “Fase 3. Servicios Web” y “Fase 4. Agregación”

Figura 72. Sección “Fase 3. Servicios W b” y “Fase 4. Agregación” del sistema.

Las seccio

La última sección del sistema “Generación semi-automática de Servicios Web” rmite

que en la sección uno, el usuario selecciona los archivo que en este caso

Por último se encuentra el botón “Salir” que permite al usuario salir del sistema.

el proceso de transformación y “Herencia” para ver las relaciones de herencia que contiene el MOO como se muestra en la Figura 71.

2.

La secccontiene los botones “Activo” e “Inactivo” para que el usuario al llegar a esta sección antes de generar los servicios Web active el servidor de aplicaciones Tomcat. También contiene el botón “Generación de Servicios” el cual se encarga de generar los servicios Web. Además contiene el botón “Relaciones de Agregación”, encargado de mostrar las relaciones de agregación existentes en el marco como se muestra en la Figura 72.

e

nes del sistema hasta ahora presentadas deben ser desarrolladas

secuencialmente sin omitir ninguno de los pasos para completar el proceso de transformación de forma adecuada. pe al usuario convertir a servicios Web los archivos seleccionados, partiendo del supuesto que el usuario sabe que los archivos pueden ser convertidos a servicios debido a que en esta sección no se realizan validaciones. Únicamente se realiza la generación de los servicios Web. Al igual serán convertidos a servicios Web cerciorándose de que el servidor “Tomcat” este activo. Al seleccionar el botón “Generación semi-automática”, los archivos serán convertidos a servicios Web.

86

Capítulo 6. Implementación de prototipo Para verificar que los servicios Web fueron generados de forma correcta, el usuario debe invocar el siguiente URL: http://localhost:8080/axis/servlet/AxisServlet.

87

Capítulo 7. Evaluación

Capítulo 7) EVALUACIÓN

En este capítulo se describe una parte de la evaluación que comprende: el plan de pruebas, un resumen de los casos de prueba y la tabla de resultados. El diseño y los casos de prueba detallados incluyendo pruebas de ejecución se encuentran en el anexo B. 7.1. Convención de nombres La convención de nombres que se sigue en este documento, la cual se muestra en la Figura 73, es utilizada a través de la evaluación del procedimiento para la obtención de MSW a partir de MOO’s y la herramienta MOO2MSW que da soporte al procedimiento.

88

Capítulo 7. Evaluación Tipo de Articulo:

01 Procedimiento. 02 Módulos de programa. 03 Programas de control. 04 Documentación de pruebas.

Procedimiento MOO2MSW01-nn Procedimiento Módulos de programa MOO2MSW02-nn Módulos de programa Programas de control MOO2MSW03-nn Programas de control, utilerías y ordenadores. Documentación de Prueba MOO2MSW04-YYZZ Plan de pruebas. MOO2MSW05-YYZZ Especificación de diseño de pruebas. MOO2MSW06-YYZZ Especificación de casos de prueba.

MOO 2 MSW00-00

Marcos Orientados a Objetos

To

Marcos de Servicios Web

Identificador Alfanumérico de tipo de artículo

Número de versión

Figura 73. Convención de nombres. 7.2. Plan de pruebas 7.2.1. Plan de prueba MOO2MSW04-01. Plan de pruebas para el procedimiento y la herramienta de conversión de MOO’s hacia MSW’s.

89

Capítulo 7. Evaluación 7.2.2. Introducción. Este documento define el plan de pruebas basado en el estándar IEEE 829 para pruebas de Software, que permitirá verificar la funcionalidad del procedimiento y la herramienta de soporte al procedimiento desarrollado para llevar MOO’s hacia MSW’s por medio de la separación de la arquitectura original del marco y su posterior conversión a servicios. El procedimiento consta de cuatro fases:

1. Análisis: Esta fase consiste en el análisis del código fuente del MOO. El objetivo principal es identificar los elementos que constituyen al marco: clases, métodos y atributos, así como también las relaciones de herencia y agregación.

El módulo de análisis del sistema realiza de forma automática este proceso. 2. Separación: Consiste en localizar racimos de clases que integran al MOO. Estos

racimos son candidatos a formar un componente o un servicio Web, colocando cada clase base en una carpeta con su nombre; las clases derivadas, se colocan en el directorio de la clase padre más abstracta en la jerarquía de herencia; y las interfaces en una carpeta con el nombre de “interfaz”. El objetivo de este módulo es facilitar al usuario la implementación de los procesos que no son desarrollados de forma automática a través de la herramienta. El módulo de separación de la herramienta realiza de forma automática este proceso y muestra en pantalla al usuario las relaciones de herencia existentes en el marco.

3. Fase de generación de servicios Web: Tiene como objetivo la conversión de los componentes del MOO identificados en el paso 2 a servicios Web. El módulo de generación de servicios de la herramienta crea de forma automática los servicios Web. En los casos en que se presentan interfaces, se elimina la interfaz y se convierte a servicio Web el conjunto de clases derivadas. Así mismo cuando se trata de una clase base la cual no presenta relaciones de agregación.

4. Fase de Integración de aplicaciones: Tiene como objetivo la restitución de las originales relaciones de agregación del MOO, por relaciones de integración de aplicaciones.

El módulo de generación de servicios de la herramienta muestra al usuario las relaciones de agregación entre clases, pero el proceso de integración se realiza de forma manual por parte del usuario.

Este procedimiento consiste en un conjunto de fases y módulos que permiten separar el MOO en diversos servicios Web. Es de interés probar que cada servicio Web obtenido es funcional y que permite al usuario utilizar sólo una parte del marco original y no su funcionalidad completa. De igual forma se requiere probar que el conjunto de servicios Web obtenidos y relacionados por la integración de aplicaciones ofrece la misma cobertura funcional que el MOO original.

90

Capítulo 7. Evaluación Los casos de prueba son tres marcos orientados a objetos que sirven de entrada al procedimiento y la salida esperada consta de una serie de servicios Web funcionales. Los casos de prueba presentados fueron elegidos para cubrir el 90% de los escenarios descritos en las fases del procedimiento. Debido a que no es fácil encontrar marcos orientados a objetos disponibles en la Web y que además contengan únicamente la parte lógica del marco sin estar mezclada con la parte de la vista, se decidió utilizar el marco estadístico por estar disponible en el CENIDET. Otro punto importante es que la tesis comprende análisis, diseño e implementación y se ha visto en tesis que realizan todas estas actividades que se sacrifica un poco la parte de pruebas, por lo que se ha acordado en lo siguiente, plantear tesis que comprendan una o dos de estas actividades únicamente para poder dar mas tiempo a la fase de pruebas, sin embargo es deseable que se realicen más pruebas en trabajos futuros. La hipótesis nula a probar es la siguiente: Con el procedimiento descrito no es posible identificar y separar las partes - componentes de un MOO para transferirlos a servicios Web. La hipótesis alterna es: Con el procedimiento descrito es posible identificar y separar las partes – componentes de un MOO para transferirlos a servicios Web. 7.2.3. Artículos a probar. Tanto las fases del procedimiento como los módulos que integran la herramienta que implementa este procedimiento, serán identificados en la pruebas como sigue:

Tabla 6. Artículos a probar. Tipo Módulo No.

Procedimiento Fase de análisis MOO2MSW01-01 Programa de aplicación Subsistema de análisis MOO2MSW02-01 Programa de aplicación Identificación de la ubicación de cada una

de las clases del marco. MOO2MSW03-01

Programa de aplicación Identificación del nombre y tipo de las clases.

MOO2MSW03-02

Programa de aplicación Identificación del tipo de métodos y atributos

MOO2MSW03-03

Programa de aplicación Identificación de relaciones de herencia MOO2MSW03-04 Programa de aplicación Identificación de interfaces e

implementaciones. MOO2MSW03-05

Programa de aplicación Identificación de las relaciones de agregación.

MOO2MSW03-06

Procedimiento Fase de separación MOO2MOS01-02 Programa de aplicación Subsistema de separación. MOO2MSW02-02

91

Capítulo 7. Evaluación Programa de aplicación Identificación de las clases base, creación

de directorios y copias de archivos a directorios.

MOO2MSW03-06

Programa de aplicación Identificación de las interfaces, creación de la carpeta interfaz y copias de archivos al directorio.

MOO2MSW03-07

Programa de aplicación Identificación de las clases derivadas, localización de la clase base más abstracta y copias de archivos al directorio.

MOO2MSW03-08

Procedimiento Fase de generación de servicios Web MOO2MSW01-03 Programa de aplicación Subsistema de generación de servicios

Web. MOO2MSW02-03

Programa de aplicación Identificación de las clases base e implementaciones no extendidas y sin relaciones de agregación.

MOO2MWS03-09

Programa de aplicación Copiar archivos al directorio de clases de Axis y compilación de archivos.

MOO2MSW03-10

Programa de aplicación Creación de los archivos de despliegue wsdd por cada clase a convertir a servicio.

MOO2MSW03-11

Programa de aplicación Despliegue de los archivos wsdd. MOO2MSW03-12 Procedimiento Identificar las jerarquías de herencia, crear

una nueva interfaz y generar servicio Web.

MOO2MSW03-13

Programa de aplicación Despliegue de las relaciones de herencia entre clases.

MOO2MSW03-14

Procedimiento Serialización. MOO2MSW03-15 Procedimiento Fase de integración de servicios MOO2MSW01-05 Programa de aplicación Subsistema de integración de

aplicaciones. MOO2MSW02-05

Programa de aplicación Despliegue de las relaciones de agregación entre clases

MOO2MSW03-16

7.2.4. Características a ser probadas. La siguiente lista describe las características que deben de ser probadas:

Tabla 7. Características a ser probadas. Diseño de prueba

Número de especificación Descripción

MOO2MSW05-01 Reconocimiento de la sintaxis de código escrito en lenguaje Java y almacenamiento de la información en la base de datos.

MOO2MSW05-02 Localización de racimos de clases del MOO original. MOO2MSW05-03 Generación de servicios Web. MOO2MSW05-04 Integración de aplicaciones.

92

Capítulo 7. Evaluación 7.2.5. Características excluidas de las pruebas. • Errores lógicos y de compilación. Se asumirá que el MOO está libre de errores lógicos

y sintácticos. • Arquitectura del marco. No se pretende determinar si la arquitectura del marco es la

correcta o la óptima. • No se tratará de probar que la totalidad de la transformación del marco es automática, la

herramienta fue desarrollada únicamente para dar soporte al procedimiento, facilitando al usuario el seguimiento del procedimiento.

• No se verificará que las clases que forman a un servicio sean las esperadas por el usuario, eso dependerá exclusivamente de la arquitectura original del marco.

• Los nombres y métodos de los servicios Web serán los contenidos en el marco original. • El número de servicios Web resultantes dependerá de la arquitectura que presente el

marco y pueden variar de 1 a n. • No se evaluará la usabilidad de la interfaz del sistema. • No se desarrollarán pruebas físicas o de elementos de hardware. 7.2.6. Enfoque. Debido a que las mediciones son principalmente de funcionalidad, la herramienta será sometida a prueba con tres MOO’s, en las que se observará: la arquitectura inicial del marco, la arquitectura después de la separación y su funcionalidad ya como servicios Web. Las pruebas a desarrollar son denominadas de caja negra ya que son centradas en las funciones, entradas y salidas. Los casos de prueba están formados por tres MOO’s de diferentes dominios:

1. El primero de ellos es un marco del dominio estadístico desarrollado por los estudiantes del CENIDET.

2. El segundo caso de prueba es un marco que calcula el área de algunas figuras geométricas tomado de Internet [45].

3. El tercer caso de prueba es similar al caso dos pero con una arquitectura diferente. Esto ayudará a asegurar que las pruebas representan efectivamente el desarrollo y uso de la herramienta completa.

7.2.7. Criterio pasa/ no pasa de casos de prueba. En la especificación de los casos de prueba, se describirán los resultados esperados para cada uno de los casos. Se considerará que una prueba ha pasado con éxito cuando los resultados esperados coincidan con los descritos en el caso de prueba. En caso de no coincidencia, se analizarán las causas y se harán las modificaciones necesarias hasta que se cumplan con los resultados esperados.

93

Capítulo 7. Evaluación 7.2.8. Criterios de suspensión y requerimientos de reanudación. En ningún caso se suspenderán definitivamente las pruebas. Cada vez que se presente que el caso no pasa una prueba, inmediatamente se procederá a evaluar y corregir el defecto, permaneciendo en la prueba de este caso hasta que ya no se presenten dificultades con él. 7.2.9. Tareas de pruebas. Las tareas a desarrollar para preparar y aplicar las pruebas son:

Tabla 8. Tareas de pruebas. Tarea Tarea precedente Habilidades especiales Responsabilidades

1. Preparación del plan de pruebas.

Terminación del análisis de marcos orientados a objetos, de servicios Web y de composición de servicios.

Conocimiento sobre el funcionamiento de marcos orientados a objetos, servicios, integración de servicios. Conocimiento del estado del arte en migración para reuso y del IEEE Std. 829.

Autora de esta tesis.

2. Preparación del diseño de pruebas.

Tarea 1. Conocimiento sobre el funcionamiento del sistema desarrollado, que incluye el proceso de separación y conversión a servicios. Conocimiento del IEEE Std. 829.


3. Preparación de los casos de prueba.

Búsqueda de casos de prueba.

Conocimiento del lenguaje de programación Java. Conocimiento de creación de servicios Web. Conocimiento de la arquitectura de los marcos.


4. Aplicación de pruebas.

Tarea 3. Conocimiento del entorno y preparación del sistema desarrollado para su ejecución.


94

Capítulo 7. Evaluación 5. Resolver los incidentes de pruebas.

Tarea 4. Conocimiento del lenguaje de programación Java, de marcos orientados a objetos, servicios Web, JavaCC.


6. Evaluación de resultados.

Tarea 5. Tarea 6.

Conocimiento de las preguntas de investigación, la hipótesis de investigación, y los objetivos de esta tesis.


7.2.10. Liberación de pruebas. La entrada especificada y la salida esperada en cada caso de prueba, serán suficientes para la comprobación del objetivo alcanzado y por lo tanto para la aceptación de las pruebas. 7.2.11. Requisitos ambientales. Las características y propiedades físicas y lógicas requeridas para el ambiente de pruebas, son las siguientes:

Equipo:

Procesador Intel PIII o superior. 256 MB de memória RAM o superior. Mouse. Teclado.

Sistema Operativo:

Windows 2000 o XP versión profesional.

Herramientas:

Java Development Kit (J2SDK SE). Java Compiler Compiler (JavaCC). Eclipse, como entorno de programación. Servidor Apache Tomcat. Servidor Apache Axís.

Casos de prueba:

Código fuente de los Marcos Orientados a Objetos.

95

Capítulo 7. Evaluación 7.2.12. Responsabilidades. Toda la responsabilidad de las pruebas recae en la autora de esta tesis. 7.2.13. Riesgos y contingencias. • Falta de tiempo: El tiempo es un factor importante que genera incertidumbre al aplicar

las pruebas, por lo que se tomarán como mínimo 3 casos de prueba, si el tiempo lo permite se extenderán las pruebas a otros casos.

• Todas las fallas que se pudieran presentar en el transcurso del desarrollo de las pruebas deberán ir resolviéndose de manera iterativa por el responsable de esta tesis, hasta que la falla no se produzca más.

7.3 Especificación de casos de prueba 7.3.1 Especificación del caso de prueba número 1. 1. Caso de prueba: MOO2MSW06-01. 2. Artículo de prueba: Marco_Estadístico. Marco_Estadístico es un MOO del dominio de cálculos estadísticos desarrollado por estudiantes del Cenidet. El marco fue desarrollado originalmente en lenguaje de programación C#, por lo que para las pruebas fue necesario su traducción al lenguaje Java. La funcionalidad del marco consiste en diferentes cálculos estadísticos a partir de los valores numéricos guardados en objetos de tipo Lista también contenidos dentro del marco. Los cálculos estadísticos implementados son:

Aritméticos: -Suma -Sumatoria -Productos sucesivos -Sumatoria de cuadrados

Tendencia central: -Media aritmética -Media armónica -Media cuadrada -Moda -Mediana

Dispersión -Varianza -Covarianza -Desviación media -Desviación estándar -Rango -Coeficiente.

96


97

Regresión -Lineal -Cuadrática -Exponencial -Potencial

Métodos de ordenamiento -Burbuja -Inserción directa -Selección directa -Shell Sort -Quick Sort

-Merge -Shaker 3. Especificación de entrada. La entrada del procedimiento es el código fuente del marco a ser explorado. El diagrama de clases correspondiente al Marco_Estadístico se muestra en la Figura 74 y la salida esperada según la descripción del procedimiento definido en el capítulo 5 se muestra en la Figura 75.


ListanElementos : int

Lista()_GetH()numElementos()_GetC()_GetAux()_SetH()_SetC()_SetAux()_IsEmpty()_Agrega()_Apila()_Inserta()_Borra()_Proximo()_Anterior()_Despliega()

cRegExponencialn : inta : floatb : floatc : float

operacion()cRegExponencial()Get_a()Get_b()Get_c()Calcula()

aRegresion

Calcula()Get_a()Get_b()Get_c()

+Reg

Elemento

Elemento()GetED()_SetED()_GetNext()_ApuntaSigi()_GetPrev()_ApuntaPrev()_ApuntaPrevNext()_ApuntaNextPrev()

PrevNext

+H+C

+Aux

+E

EDVal1 : floatVal2 : float

ED()_SetVal1()_SetVal2()_GetVal1()_GetVal2()_Show()

+eDatos+Edatos

cRegPotencialn : inta : floatb : floatc : float

operacion()cRegPotencial()Get_a()Get_b()Get_c()Calcula()

+Reg

+E

+Edatos

cRegCuadratican : inta : floatb : floatc : float

operacion()cRegCuadratica()Get_a()Get_b()Get_c()Calcula()

cRegLineala : floatb : floatc : floatn : int

operacion()Get_a()Get_b()Get_c()cRegLineal()Calcula()

aAlgoritmo

operacion()

aCalculoDispersion

Calcular()

aCalculoTendencia

Calcular()

aOrdenamiento

_Ordenar()

aCalculoAritmetico

operacion()Calcular()Calcular()

cSumasuma : float

Calcular()

cSumatoriasumatoria : float

Calcular()

cSumatoriaCuadradossumatoriaQ : float

Calcular()

cProductosSucesivosproducto : float

operacion()Calcular()

cCovarianzaCoVarianza : float


cCoheficienteCoheficiente : float


cDesviacionEstandarDesviacionE : float


cDesviacionMediaDesviacionM : float


ServicioTendenciaCentralMediaAritmetica : float

Calcular()

ServicioMetodoOrdenamiento

Ordenar()

cRangoRango : float


cVarianzaVarianza : float


cMediaAritmeticaMediaAritmetica : float


cMediaArmonicaMediaArmonica : float


cMediaCuadradaMediaCuadrada : float


cMediaGeometricaMediaGeometrica : float


cMedianaMediana : float


cModaModa : float


cBurbuja

operacion()_Ordenar()_Burbuja()_Burbuja()

cInsercionDirecta

operacion()_Ordenar()_InsercionDirecta()_InsercionDirecta()

cMerge

operacion()_Ordenar()_Merge()_Mezcla()_Mezcla()

cQuickSort

operacion()_Ordenar()_Ordena()_Particionar()_Particionar()cSeleccionDirecta

operacion()_Ordenar()_SeleccionDirecta()_SeleccionDirecta()

cShaker

operacion()_Ordenar()_Shaker()_Shaker()

cShellSort

operacion()_Ordenar()_Shell()_Shell()

98

Figura 74. Diagrama del caso de prueba MOO2MSW06-01.


99

4. Especificación de salida esperada. Ver la Figura 75. El Marco_Estadístico esta compuesto por 6 racimos organizados por jerarquías de herencia. En cinco de ellos la clase base es una interfaz: aAlgoritmo, aRegresion, aCalculoDispersión, aCalculoTendencia y aOrdenamiento, según lo que marca el procedimiento para este caso, las interfaces desaparecen y las clases derivadas son convertidas a servicios Web cada una de forma independiente, formando los servicios Web: cRegExponencial, cRegPotencial, cRegCuadratica y cRegLineal, correspondientes al racimo de aRegresion; cCoeficiente, cCovarianza, cDesviacionEstandar, cDesviacionMedia, cRango y cVarianza correspondientes, al racimo de aCalculoDispersión; cMediaAritmetica, cMediaArmonica, cMediaCuadrada, cMediaGeometrica, cMediana y cModa, correspondientes al racimo de aCalculoTendencia; cMerge, cInsercionDirecta, cBurbuja, cShaker, cShellSort, cQuickSort y cSeleccionDirecta, correspondientes al racimo de aOrdenamiento. El otro racimo corresponde a aCalculoAritmetico en el que la clase base no es una interfaz sino una clase abstracta con métodos y atributos públicos, por lo que según lo que marca el procedimiento, se crea una nueva clase “CalculoAritmetico” en la que se especifican los diferentes métodos de las clases derivadas, generando un único servicio Web “CalculoAritmetico” con cuatro cálculos disponibles: Suma, Sumatoria, Sumatoria de Cuadrados y Productos sucesivos. Además de los 6 racimos cuenta con dos clases: ServicioTendenciaCentral y ServicioMetodoOrdenamiento las cuales son convertidas a servicios Web de forma independiente debido a que no pertenecen a ninguna jerarquía de herencia. También cuenta con las clases ED, Elemento y Lista, estas tres clases son muy importantes debido a que los datos con los que realizan los cálculos todas las clases provienen de los elementos contenidos en un objeto de tipo Lista, estas clases son convertidas a servicios Web de forma independiente debido a que no pertenecen a una jerarquía de herencia. En todos los casos, para realizar la conversión a servicios Web fue necesario implementar el proceso de serialización, debido a que los parámetros que reciben los métodos de los cálculos de todos los servicios son objetos de tipo Lista. La descripción completa de los casos de prueba se encuentra en el anexo B.


deployment Class Model

EDElementoLista

CalculoAritmetico

cRegLineal

cRegCuadratica

cRegPotencial

cRegExponencial

cCoeficiente

cCovarianza

cDesv iacionEstandar

cDesv iacionMedia

cRango

cVarianza

cMediaAritmetica

cMediaArmonica

cMediaCuadrada

cMediaGeometrica

cMediana

cModa

cMerge

cInsercionDirecta

cBurbuja

cShaker

cShellSort

cQuickSort

cSeleccionDirecta

Serv icioMetodoOrdenamiento

Serv icioTendenciaCentral

Figura 75. Servicios Web esperados del caso de prueba MOO2MSW06-01.

100


101

5. Especificación de salida obtenida. Como se ilustra en la Figura 76, la salida obtenida corresponde al conjunto de servicios Web esperados. La especificación completa de la salida obtenida se muestra en el anexo B.

deployment Class Model

EDElementoLista

CalculoAritmetico

cRegLineal

cRegCuadratica

cRegPotencial

cRegExponencial

cCoeficiente

cCovarianza

cDesv iacionEstandar

cDesv iacionMedia

cRango

cVarianza

cMediaAritmetica

cMediaArmonica

cMediaCuadrada

cMediaGeometrica

cMediana

cModa

cMerge

cInsercionDirecta

cBurbuja

cShaker

cShellSort

cQuickSort

cSeleccionDirecta

Serv icioMetodoOrdenamiento

Serv icioTendenciaCentral

Figura 76. Servicios Web obtenidos del caso de prueba MOO2MSW06-01.

Capítulo 7. Evaluación 7.3.2. Caso de prueba número 2. 1. Caso de prueba: MOO2MSW06-02. 2. Artículo de prueba: Área _FigurasGeométricas. El artículo a probar es un MOO desarrollado para calcular el área de las siguientes figuras geométricas:

Cuadro Paralelogramo Trapezoide Rectángulo Elipse Circulo

El caso de prueba fue obtenido del documento “Principios de diseño” en la referencia [44] y extendido agregándole las clases cElipse, cParalelogramo, cRectangulo y cTrapezoide, para aumentar su funcionalidad. 3. Especificación de entrada. La entrada del procedimiento es el código fuente del marco de este caso de prueba. El diagrama de clases correspondiente al marco Área_FigurasGeométricas se muestra en la Figura 77.

aFigura

area()

cCirculoradio : double

cCirculo()area()

cCuadradolado : double

cCuadrado()area()

cElipseradio1 : doubleradio2 : double

cElipse()area()

cParalelogramobase : doubleh : double

cParalelogramo()area()

cRectanguloancho : doublealto : double

cRectangulo()area()

cTrapezoidebase1 : doublebase2 : doubleh : double

cTrapezoide()area()

Figura 77. Diagrama de clases Área _FigurasGeométricas.

4. Especificación de salida esperada. El caso de prueba Área_FigurasGeométricas está formado por una jerarquía de herencia en la que la clase base es una interfaz. Por lo que según la especificación del procedimiento para estos casos, la interfaz se separa y las clases derivadas son convertidas a servicios Web

102


Figura 78. Servicios Web esperados del caso de prueba MOO2MSW06-02.

5. Especificación de salida obtenida.

a salida obtenida fue la correcta según la descripción del procedimiento. El conjunto de

7.3.3. Caso de prueba número 3.

. Caso de prueba: MOO2MSW06-03.

. Artículo de prueba: Área _FigurasGeométricas.

l artículo a probar es un MOO desarrollado para calcular el área de algunas figuras

Área _FigurasGeométricas.

de forma independiente. Formando los servicios Web: cCirculo, cRectangulo, cElipse, cTrapezoide, cParalelogramo y cCuadrado. La salida esperada es el conjunto de servicios Web que se muestran en la Figura 78, la especificación completa de la salida esperada se muestra en el anexo B.

class Frameworks

cCirculo cRectangulocElipse cTrapezoidecCuadrado cParalelogramo

Lservicios Web obtenidos en la Figura 78 corresponden a los servicios Web esperados en la Figura 79. La especificación completa de la salida obtenida se muestra en el anexo B.

class Frameworks

Figura 79. Servicios Web obtenidos del caso de prueba MOO2MSW06-02.

1 2 Egeométricas, y se muestra en la Figura 80. Este caso de pruebas es similar al caso de pruebas MOO2MSW06-02, con la característica principal de que la clase base es una clase abstracta y no una interfaz. El objetivo es diferenciar cómo se comporta el procedimiento en la fase específica de generación de servicios Web.

cCirculo cRectangulocElipse cTrapezoidecCuadrado cParalelogramo

aFigura

Figura 80. Diagrama de clases

x : inty : int

aFigura()area()

cCirculoradio : double

cCirculo()area()

cCuadradolado : double

cCuadrado()area()

cElipseradio1 : doubleradio2 : double

cElipse()area()

cParalelogramobase : doubleh : double

cParalelogramo()area()

cRectanguloancho : doublealto : double

cRectangulo()area()

cTrapezoidebase1 : doublebase2 : doubleh : double

cTrapezoide()area()

103

Capítulo 7. Evaluación 4. Especificación de

rea_FigurasGeométricas está formado por una jerarquía de herencia en la que la clase

La salida esperada es el servicio Web que se muestran en la Figura 81. La

Figura 81. Servicio MOO2MSW06-03.

5. Especificación de salida obtenida.

a salida obtenida fue la correcta según la descripción del procedimiento. El conjunto de

a salida obtenida es el servicio Web que se muestran en la Figura 82.

Figura 82. Servici OO2MSW06-03.

7.4. Tabla de resultados

a siguiente tabla muestra los resultados obtenidos en cada una de las fases del

salida esperada. Ábase es una clase abstracta con atributos protegidos y métodos públicos. Además, las clases derivadas contienen llamadas al constructor de la clase padre. Por lo que según la especificación del procedimiento para este tipo de casos se genera una clase nueva “ServicioFigurasGeometricas” en la que se describen los métodos para invocar a las clases derivadas: Circulo, Cuadrado, Elipse, Paralelogramo, Rectángulo y Trapezoide. Por último se convierte la nueva clase generada en servicio. El servicio Web resultante es únicamente “ServicioFigurasGeometricas” con 5 cálculos diferentes. especificación completa de la salida esperada se muestra en el anexo B.

Web esperados del caso de prueba

Lservicios Web obtenidos de la Figura 81 corresponden a los servicios Web esperados de la Figura 82. La especificación completa de la salida obtenida se muestra en el anexo B. L

o Web obtenido del caso de prueba M

Lprocedimiento, tanto los procesos que se desarrollan automáticamente por la herramienta, como aquellos que se realizan de forma manual por parte del usuario. Las pruebas desarrolladas fueron tres MOO’s en las que se tratan de cubrir el mayor número de escenarios posibles.

104


Tabla 9. Tabla de resultados. Fases Caso de prueba:

MOO2MSW06-01 Caso de prueba:

MOO2MSW06-02 Caso de prueba:

MOO2MSW06-02-1

Análisis MOO2MSW03-01 MOO2MSW03-02 MOO2MSW03-03 MOO2MSW03-04 MOO2MSW03-05 Separación MOO2MSW03-06 MOO2MSW03-07 MOO2MSW03-08 Generación de Servicios Web

MOO2MWS03-08 MOO2MWS03-09 MOO2MWS03-10 MOO2MWS03-11 MOO2MWS03-12 MOO2MWS03-13 MOO2MWS03-14 Integración de aplicaciones

Se puede observar que en los tres casos de prueba, cada una de las fases fue

concluida satisfactoriamente, logrando tener una serie de servicios Web funcionales a partir de un marco orientado a objetos. Por lo tanto la hipótesis nula resulto ser falsa y la tesis alterna verdadera. El desarrollo completo de las pruebas que dan soporte a la tabla de resultados se describe en el anexo B.

105

Capítulo 8. Conclusiones y trabajo futuro

Capítulo 8) CONCLUSIONES Y TRABAJO FUTURO

En este capítulo se describen las conclusiones a las que se llegó al término de la investigación presentada en el trabajo de tesis, así como algunos puntos que pueden ser considerados para futuros proyectos. 8.1. Conclusiones La Migración de MOO’s a servicios Web permite obtener diversos servicios de un dominio de aplicaciones en específico debido a que los MOO’s son diseñados para un dominio en particular. Los servicios Web generados quedan a disposición de los desarrolladores de software para que puedan utilizarlos en la generación de nuevas aplicaciones de software. En el presente trabajo de tesis se definió un procedimiento para la generación de servicios Web a partir de MOO’s y para dar soporte al procedimiento se desarrolló la herramienta nombrada MOO2MSW.

106

Capítulo 8. Conclusiones y trabajo futuro Las pruebas realizadas demuestran que siguiendo el procedimiento y empleando la herramienta de apoyo, se cumple la hipótesis: “Con el procedimiento descrito es posible identificar y separar las partes – componentes de un MOO para transferirlos a servicios Web”. Las aportaciones de esta tesis son: a) Análisis de escenarios para el proceso de transformación de MOO’s a MSW’s.

• Con el análisis desarrollado se identificaron una serie de escenarios presentes en la localización de los componentes que integran a un MOO para su transformación a servicios Web. Este análisis forma la base para la generación de nuevos procedimientos de transformación.

b) Procedimiento para la obtención de Marcos de Servicios Web a partir de Marcos Orientado a Objetos.

• El procedimiento propuesto tiene la intención de reducir la curva de aprendizaje a la que comúnmente se tienen que enfrentar los usuarios de los MOO’s debido a la arquitectura tan grande y compleja que presentan. Al localizar los componentes que integran un marco y convertirlos a servicios Web, el usuario ya no tiene que preocuparse por entender la arquitectura completa del marco sino únicamente conocer la especificación contenida en el WSDL de los servicios Web generados, para crear un cliente que los invoque. Es decir las entradas, proceso, salidas y dirección de su ubicación remota.

• Los MOO’s son generados para trabajar en un ambiente especifico, es decir en una empresa en particular. Al transformar los MOO’s a servicios Web, la empresa puede poner a disposición estos servicios, en un repositorios UDDI para que otras empresas puedan beneficiarse de su funcionamiento, dejando de ser de uso centralizado para pasar a ser de uso distribuido a través de la Web.

• Los MOO’s son desarrollados para un dominio especifico, entre más maduro sea el marco más completo es el dominio al que representa.

Al separar los MOO’s para formar diferentes servicios Web, se obtienen una serie de servicios que forman parte de un dominio en particular. Es decir, se enriquece el directorio UDDI con múltiples servicios de un mismo dominio.

• Mediante el uso del procedimiento se generan componentes de diferentes tamaños, permitiendo al usuario utilizar únicamente las partes del marco que son de su interés y no la arquitectura completa.

c) Herramienta de transformación MOO2MWS.

• Se implementaron las fases de análisis, separación y generación de servicios Web del procedimiento de transformación propuesto, para facilitar al usuario el desarrollo de las fases que lo componen.

107

Capítulo 8. Conclusiones y trabajo futuro d) Casos de estudio que demuestran la efectividad del procedimiento.

• La evaluación demuestra que mediante el seguimiento del procedimiento descrito, es factible obtener servicios Web funcionales a partir de la separación de los componentes que integran a los MOO’s.

8.2 Problemas enfrentados

• Los servicios Web son desarrollados, principalmente, para trabajar con datos de entrada de tipo primitivo, los cuales puedan estar disponibles para todos los usuarios. Para trabajar con instancias de clases como parámetros de entrada deben de usarse técnicas de serialización que permitan descomponer el objeto para la invocación del servicio. Aun así, es necesario que el usuario conozca las características que contiene el objeto para formar uno igual, serializarlo e invocar al servicio. Si se invoca el servicio con un objeto diferente al que este maneja, se puede llamar a métodos y atributos que no existan en el objeto enviado por el cliente. Por lo que se propone, realizar estudios que busquen alternativas para solucionar este problema, como puede ser generar documentos WSDL’s que describan en caso de que el parámetro sea un objeto, la forma en la que está compuesta el objeto, o una plantilla para crearlo.

• Los diferentes ambientes para crear servicios Web, lo hacen a partir de una clase, por lo que para llevar racimos formados por jerarquías de herencia en un MOO es necesario crear una clase en la que se especifiquen los métodos de toda la jerarquía de herencia que van a formar parte del servicio.

• La integración de aplicaciones permite sustituir las relaciones de agregación que contiene un MOO por invocación entre servicios. Sin embargo, genera dependencias entre ellos, es decir la existencia de un servicio, depende de la existencia de otro, de tal forma que si en un momento dado un servicio Web llega a no estar disponible, o no se pude establecer conexión con él, todos los servicios que dependan de éste dejan de funcionar, violando el principio número 6 de una SOA, el cual dice que los servicios tienen que ser independientes unos de los otros, es decir tener bajo acoplamiento.

8.3. Trabajo Futuro Como trabajo futuro se propone automatizar en su totalidad las fases de:

• Separación. • Generación de servicios Web. • Integración de aplicaciones.

Así como también el proceso de serialización y deserialización, con el objetivo de facilitar lo más posible la tarea de transformación al usuario.

108

Capítulo 8. Conclusiones y trabajo futuro Otro trabajo futuro es explorar con mayor cobertura los escenarios, con el fin de agotar todas las alternativas que pudieran presentarse en el proceso de localización de los componentes que integran al marco, tomando en cuenta: riesgos, ventajas y desventajas de la separación. Uno más, consiste en desarrollar nuevos procedimientos y herramientas, que generen otras opciones de transformación de MOO’s a servicios Web, con técnicas e ideas distintas. Una solución alterna para distinguir los componentes que serán candidatos a transformar a servicio Web, es seleccionando el conjunto de clases que participan colaborativamente en un caso de uso, no importando si estas clases se integran por agregación o por herencia, ni importando si se considera una mima clase de objetos en varios compuestos de un servicio.

109

Referencias Referencias [1] Santaolaya, R. “Modelo de representación de patrones de código para la construcción de componentes reusables”. Tesis de Doctorado, Departamento de Ciencias Computacionales, Centro de Investigación en Computación, IPN, 2003. [2] Karlsson, E. “Software Reuse. A Holistic Approach”. John Wiley & Sons Ltd. 1995. [3] García, F. J. Marques, J. M. Maudes J. M. “Análisis y Diseño Orientado al Objeto para Reutilización”. 1997. Disponible en línea en: http://www.giro.infor.uva.es/Publications/1997/GMM97a/. Fecha de consulta 08/Agosto/2007. [4] Guerrero, R. Arellano, L. Hernández, F. “Tipo de Datos Abstractos”. Disponible en línea en: http://www.geocities.com/abstractomx/tda.html. Fecha de consulta: 08/Agosto/2007. [5] Gamma, E. Helm, R. Johnson, R. y Vlissides, J. “Design Patterns. Elements of Reusable Object-Oriented Software”. Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA. 1995. [6] Alexander, C. Ishikawa, S. Silverstein, M. Jacobson, M. Fikdahl, I. Angel, S. “A Pattern Language”. Oxford University Press, Nueva York, 1977. [7] Prieto, F. Crespo, Y. Marques, J. Laguna, M. “Análisis de Conceptos Formales como Soporte para la Construcción de Frameworks de Dominio”. II Jornadas de Trabajo DOLMEN, I+D Computación, Vol. 2, ISSN 1665-238X Análisis. Valencia, España. 2003 Disponible en línea en: http://www.giro.infor.uva.es/Publications/2002/PCML02/habana.pdf. Fecha de consulta: 08/Agosto/2007. [8] García, F. Barras, J. Laguna, M. Marques, J. “Líneas de Productos, Componentes, Frameworks y Mecanos”. Informe Técnico – Technical Report DPTOIA-IT-2002-004 Marzo. Cauca Colombia. 2002. Disponible en línea en: http://tejo.usal.es/inftec/2002/DPTOIA-IT-2002-004.pdf. Fecha de revisión: 08/Agosto/2007. [9] Mattsson, M. Bosch, J. “Framework Composition: Problems, Causes and Solutions”. 23rd Technology of Object Oriented Languages and Systems. IEEE Computer Society. Santa Barbara, CA. 1997. Disponible en línea en: http://citeseer.ist.psu.edu/cache/papers/cs/612/http:zSzzSzbilbo.ide.hk- r.se:8080zSz~boschzSzpaperszSzfrwkcomp.pdf/framework-composition-problems- causes.pdf. Fecha de revisión: 08/Agosto/2007. [10] Parsons, D. Rashid, A. Speck, A. Telea, A. “A “framework” for Object Oriented Frameworks Design”. Technology of Object-Oriented Languages and Systems ACM 1999;

110

Referencias también como informe de la investigación, RANA 99-37, Eindhoven Univ. of Technology. 2003. Disponible en línea en: http://www.win.tue.nl/~alext/ALEX/PAPERS/TOOLS99/fwk.pdf. Fecha de revisión: 08/Agosto/2007. [11] Kirk, D. Roper, M. Wood, M. “Identifying and Addressing Problems in Framework Reuse”. 13th International Workshop on Program Comprehension (IWPC 2005). IEEE Computer Society. St. Louis, MO. 2005. [12] Pereira, R. Freiberger, R. “Helping Object-Oriented Framework Use and Evaluation by means of Historical Use Information”. 19th International Conference on Automated Software Engineering (ASE 2004). IEEE Computer Society. Linz, Austria. 2004. [13] Fuentes, L. Troya, J, M. Vallecillo, A. “Lección 1 Desarrollo de Software basado en componentes”. IV Congreso de Automatización y Control. Mérida, Venezuela. 2003. Disponible en línea en: www.lcc.uma.es/~av/Docencia/Doctorado/tema1.pdf. Fecha de revisión: 08/Agosto/2007. [14] López, O. “Estudio e implementación de Web Services”. Informe Técnico, Java Hispano, 2002. Disponible en línea en: www.javahispano.org/tutorials.type.action?type=j2ee - 38k. F. Fecha de revisión: 07/Febrero/2006. [15] Bodas, D. J. “Introducción a la programación distribuida”. Disponible en línea en: www.puntoedu.edu.ar/comunidades/ing/informatica/+info/programacion_distribuida_en_java.pdf. Fecha de revisión: 08/Agosto/2007. [16] Caramazana, A. “CORBA/DCOM Dos mundos unidos”. Disponible en línea en: http://albertocc.tripod.com/pdf/CORBA-DCOM.pdf. Fecha de revisión: 08/Agosto/2007. [17] Ávila, E. “Método de refactorización de software legado para desacoplar el código de la interfaz al usuario del código de la parte lógica de la aplicación”, Tesis de Maestría, Departamento de Ciencias Computacionales, Centro Nacional de Investigación y Desarrollo Tecnológico. Septiembre 2004. 110 [18] Bodas, D. J. “Introducción a la programación distribuida”. CES Felipe II (UCM). Disponible en línea en: http://www.puntoedu.edu.ar/comunidades/ing/informatica/+info/programacion_distribuida_en_java.pdf. Fecha de revisión: 08/Agosto/2007. [19] Entorno de acs. “Comparativo CORBA y DCOM”. Disponible en línea en: http://acsblog.es/svn/pfc/CORBAvsDCOM/CORBAvsDCOM.html. Fecha de revisión. 08/Agosto/2007

111

Referencias [20] Blog Tecnológico de Entel IT Consulting, SA. “¿Quién define las pautas de SOA?”. Disponible en línea en: http://tecnoblog.entel.es/?p=12#more-12. Fecha de revisión 08/Agosto/2007. [21] Erl, T. “Service Oriented Architecture”, Prentice hall, ISBN 0-13-185858-0. Pág. 53. 2006. [22] Canfora, G. Fasolino, A.R. Frattolillo, G. Tramontana, P. “Migrating interactive legacy systems to Web services”. Software Maintenance and Reengineering, CSMR 2006. Proceedings of the 10th European Conference. IEEE Computer Society. Bari, Italy. 2006. [23] Osorio, T. Garcia, A. Andres, C. “Migración de Sistemas de Información Legados a Servicios Web como plataforma para lograr integración b2b”. Tesis de maestría en ingeniería industrial en la Universidad de los Andes. Bogota, Colombia. 2005. [24] Fuentes, J.M. Corella, M.A. Castells, P. Rico, M. “Generación semi-automática de servicios Web”. I Jornadas Científico-Técnicas en Servicios Web (JSWEB 2005). Granada España. 2005. Disponible en línea en: nets.ii.uam.es/~sws/publications/jsweb05-extended.pdf. Fecha de revisión 08/Agosto/2007. [25] Bodhuin, T. Guardabascio, E. Tortorella M. “Migrating COBOL Systems to the Web by using de MVC Design Pattern”. Ninth Working Conference on Reverse Engineering. IEEE Computer Society. Richmond, Virginia 2002. [26] Harry M. Sneed & Stephan H. Sneed. “Creating Web Services from Legacy Host Programs”. 5th International Workshop on Web Site Evolution. IEEE, IEEE Computer Society. Amsterdam, The Netherlands. 2003. [27] Ping, Y. Lu, J. Lau, TC. Kontogiannis, K. Tong, T. Yi, B. “Migration of Legacy Web Applications to Enterprise Java™ Environments – Net.Data® to JSP™ Transformation*”. IBM Centre for Advanced Studies Conference, 2003 conference of the Centre for Advanced Studies on Collaborative research. Toronto, Ontario, Canada. 2003. [28] O’Brien, L. Smith, D. Lau, Lewis, G. “Supporting Migration to Services using Software Architecture Reconstruction”. 13th IEEE International Workshop on Software Technology and Engineering Practice. IEEE Computer Society. , 2005. [29] Moreno, A. “Programación Orientada a Objetos”. MARCOMOBO, S.A. ISBM: 9788426714. EAN: 9788426714524. Pág. 6. [30] Wikipedia La enciclopedia libre. “Programación Orientada a Objetos”. Disponible en línea en: http://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_objetos. Fecha de revisión: 08/Agosto/2007. [31] García, J. Marqués, J. Maudes, J. “Análisis y Diseño Orientado al Objeto para Reutilización”. Reporte Técnico, TR-GIRO-01-97V2.1.1. Universidad de Valladolid. 1997

112

Referencias [32] Mohamemed, F. Douglas, S. “Object-Oriented Application Frameworks”. Editorial for the Communications of the ACM, Special Issue on Object-Oriented Application Frameworks Vol. 40, No. 10. Disponible en línea en: http://www.cs.wustl.edu/~schmidt/CACM-frameworks.html. 1997. Fecha de revisión 05/Febrero/06. [33] Cubillos, J. Burbano, J. Corrales, J. Ordoñez, J. “Composición Semántica de Servicios Web”, Grupo de Ingeniería de Telemática, Universidad del Cauca, Popayán, Colombia. Disponible en línea en: http://www.cintel.org.co/media/temacentral_3_14.pdf. Fecha de revisión: 08/Diciembre/05. [34] Proyecto LEAD, Rol Plugins. COAL Group. Universidad de la Republica. Uruguay. 2004. Disponible en línea en: http://www.fing.edu.uy/inco/grupos/coal/investigacion/proyectos/lead/docs/SegundaListav2.pdf. Fecha de revisión: 13/Agosto/2007. [35] Cibernetica. Disponible en línea en: http://www.cibernetia.com/manuales/servicios_web/3_soap.php. Fecha de revisión: 13/Agosto/2007. [36] Cid, J. “Soporte JWSDP en Sun JAVA System Application Server (SJSAS)”. 2006. Disponible en línea en: http://blogs.sun.com/jaimecid/entry/soporte_jwsdp_en_sjsas. Fecha de revisión. 13/Agosto/2007. [37] Sun Microsystem. The Java Web Service Tutorial. Disponible en línea en: http://java.sun.com/webservices/docs/1.6/tutorial/doc/index.html. Fecha de revisión: 13/Agosto/2007. [38] Srivastava, R. “The Evolution of JAXP”. 2005. Disponible en línea en: http://www.xml.com/pub/a/2005/07/06/jaxp.html. Fecha de revisión: 13/Agosto/2007. [39] Gupta, A. Getting Started with JAX-RPC. Disponible en línea en: http://java.sun.com/developer/technicalArticles/WebServices/getstartjaxrpc. Fecha de revisión. 13/Agosto2007. [40] Resumen del trabajo de fin de carrera. “Coordinación de procesos de negocios en entornos de servicios Web: implementación de “Business Activity”. Disponible en línea en: http://internetng.dit.upm.es/business%20activity.pdf. Fecha de consulta: 15/Agosto/2007. [41] Miedes, E. “Serialización de Objetos”. Universidad Politécnica de Valencia. Disponible en línea en: http://www.javahispano.org/download/articulos/serializacion.pdf. Fecha de consulta: 15/Agosto/2007. [42] José, Prieto. “Los procedimientos de trabajo”. 2005. Disponible en línea en: http://www.ucm.es/info/Psyap/taller/procedimientos/sld002.htm

113

Referencias [43] Andrea, G. “java1.4.jj”. Disponible en línea en: www002.upp.so-net.ne.jp/mamewo/sources/javaCC/parse/java_callgraph.jj - 26k –. Fecha de revisión 15/Julio/07. [44] Berzal, F. “OPP – “Principios de diseño”. Disponible en línea en:

http://elvex.ugr.es/decsai/java/pdf/AC-interfaces.pdf . Fecha de revisión 15/Julio/07.

114

Anexo A. Análisis y diseño del sistema

Anexo A) ANÁLISIS Y DISEÑO DEL SISTEMA

En este anexo se describe el análisis de escenarios de la herramienta MOO2MSW con sus correspondientes diagramas de actividad, así como también los diagramas de actividad del diseño de la herramienta. A1. Análisis del Sistema A1.1. Definición de Escenarios. 1. Módulo de Análisis.

ID : CU-1 El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la Figura 83.

Nombre de caso de uso:

Analizar código.

115


Creador: Elvia Araiza Lizarde Ultima modificación:

Elvia Araiza Lizarde

Fecha de creación:

27/02/07 Fecha de última modificación:

27/02/07

Actores: Usuario Descripción: Permite al usuario analizar los archivos fuentes que forman al MOO

y obtener características importantes para la conversión del marco a servicios Web. La información obtenida es almacenada en una base de datos.

Precondiciones: 1. El usuario debe de ingresar los archivos que forman al MOO.

2. Los archivos deben de existir. 3. Deben de tener la extensión .java. 4. Deben de estar libre de errores lógicos y de compilación.

Poscondiciones: 1. Se contará con la información resultante del análisis, disponible en una base de datos.

Escenario de éxito:

1. El usuario selecciona en la ventana del cuadro de diálogos los archivos que forman al MOO.

2. Se pulsa el botón analizar. 3. Se realiza la conexión a la base de datos. 4. Se eliminan los datos contenidos en la base de datos. 5. Se invoca al método analizar de la clase JavaParser con

cada uno de los archivos seleccionados. 6. Se identifican las características de cada archivo. 7. Se almacena la información en variables temporales. 8. Se insertan los datos en las tablas correspondientes. 9. Se cierra la conexión a la base de datos. 10. Termina el proceso.

Escenario de fracaso 1:

1. El usuario selecciona los archivos que forman al MOO. 2. El sistema no encuentra los archivos especificados por el

usuario. 3. Termina el proceso

Escenario de fracaso 2: 1. El usuario selecciona los archivos que forman al MOO. 2. Se pulsa el botón analizar. 3. Se realiza la conexión a la base de datos. 4. Falla la conexión a la base de datos. 5. Se envía mensaje de error. 6. Se cierra la conexión. 7. Termina el proceso.

Escenario de fracaso 3: 1. El usuario selecciona los archivos que forman al MOO. 2. Se pulsa el botón analizar. 3. Se realiza la conexión a la base de datos. 4. Se eliminan los datos contenidos en la base de datos. 5. Se invoca al método analizar de la clase JavaParser con

cada uno de los archivos indicados. 6. Se identifican las características de cada archivo. 7. Se almacena la información en variables temporales. 8. Los datos a insertar ya existen, por lo que se genera

duplicidad en la llave primaria.

116


9. Se cierra la conexión. 10. Termina el proceso.

Incluye: CU-1.1 Identificar características de la(s) clase(s), CU-1.2 Almacenar información.

Suposiciones: Se supone que el usuario cuenta con el sistema original instalado en su máquina.

Eliminar el contenido de la base de datos

Llamar al método analizar de la clase JavaParser

Seleccionar los archivos del MOO

Pulsar el botón Analizar

Identificar caracteristicas del MOO

Almacenar información en variables temporales

Insertar la información en la base de datos

Realizar conexión a la base de datos

Si se encuentra el archivo

Error en la conexión

falla la conexión

conexión exitoda

Archivo no encontrado

Si no se encuentra el archivo

Cerrar conexión

Figura 83. Diagrama de actividad del caso de uso CU-1.

117


ID : CU-1.1 El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la Figura 84.


Identificar características de la(s) clase(s).



Fecha de creación:


27/02/07

Actores: Analizar código. Descripción: Permite identificar características en las clases que son importantes

para el módulo de separación. Las características identificadas son: nombre del archivo, nombre de la clase, tipo de métodos, tipo de atributos, clases derivadas e implementadas y relaciones de agregación.

Precondiciones: 1. Los archivos deben de existir. 2. Deben de tener la extensión .java. 3. Deben de estar libre de errores lógicos y de compilación. 4. Debe de existir una conexión a la base de datos.

Poscondiciones: 1. Se guardará en variables temporales la información resultante del análisis.


1. Se manda llamar al método analizar de la clase JavaParser con cada uno de los archivos del MOO.

2. Se identifican las características de cada archivo: nombre del archivo, nombre de la clase, tipo de métodos, tipo de atributos, relaciones de herencia, relaciones de agregación e interfaces.

3. Se almacena la información en variables temporales. 4. Termina el proceso.

Incluye: Suposiciones: Se supone que el usuario cuenta con el sistema original instalado en

su máquina.

Llamar al método analizar de la clase JavaParser

Identificar caracteristicas del MOO

Almacenar información en variables temporales

Figura 84. Diagrama de actividad del caso de uso CU-1.1

118




Almacenar información.



Fecha de creación:


27/02/07

Actores: Analizar código. Descripción: Permite al sistema almacenar la información obtenida en el

proceso de análisis sintáctico en una base de datos. Precondiciones: 1. Se debe de establecer la conexión a la base de datos.

2. Las tablas deben de estar vacías. 3. El proceso anterior debe concluir exitosamente. 4. La información debe estar guardada en variables

temporales. Poscondiciones: 1. Se almacena en la base de datos la información de las

variables temporales identificadas en el proceso anterior. Escenario de éxito:

1. Se realiza la conexión a la base de datos. 2. Se inserta la información de las variables temporales en

la base de datos. 3. Se cierra la conexión. 4. Termina el proceso.

Escenario de fracaso 1: 1. Se realiza la conexión a la base de datos. 2. falla la conexión. 3. Termina el proceso.

Escenario de fracaso 2: 1. Se realiza la conexión a la base de datos. 2. Los datos a insertar ya existen, por lo que se genera

duplicidad en la llave primaria. 3. Se cierra la conexión. 4. Termina el proceso.

Incluye: Suposiciones: Se supone que el usuario cuenta con el sistema original instalado

en su máquina.

119


Conexión exitosa

Llave primaria duplicada

Si el registro existe

Error en la conexión

falla la conexión

Insertar la información en la base de datos

si el registro no existe

Realizar la conexión

Cerrar conexión

Figura 85. Diagrama de actividad del caso de uso CU-1.2.

2. Módulo de Separación.



Separar el MOO.



Fecha de creación:


27/02/07

Actores: Usuario y Base de Datos. Descripción: Permite al usuario agrupar las clases relacionadas en componentes

según su colaboración. Precondiciones: 1. La etapa de análisis debe de ser finalizada exitosamente.

2. Deben existir clases registradas en la base de datos. 3. El usuario debe pulsar el botón separar de la interfaz.

Poscondiciones: 1. Se contará con las clases que forman al marco separadas en directorios según su tipo (clases bases, clases derivadas e interfaces).


1. El usuario pulsa el botón separar de la herramienta. 2. Se realiza la conexión a la base de datos. 3. Se extrae el nombre de las clases y su ubicación. 4. Se cierra la conexión a la base de datos. 5. Se crean los directorios. Un directorio por cada clase base o

interfaz respectivamente. 6. Se hace una copia de cada clase y se ubica en el directorio

correspondiente. 7. Se muestran al usuario las relaciones de herencia en

120


pantalla. 8. Termina el proceso.

Escenario de fracaso 1: 1. El usuario pulsa el botón separar de la interfaz. 2. Se realiza la conexión a la base de datos. 3. Falla la conexión a la base de datos. 4. Se envía un mensaje de error de conexión al usuario. 5. Se cierra la conexión 6. Termina el proceso.

Incluye: CU-2.1 Separar clases base, CU-2.2 Separar clases derivadas y CU-2.3 Separar interfaces.

Suposiciones: Se supone que el usuario cuenta con la base de datos creada y el sistema original instalado en su máquina.

Pulsar el botón separar

Conexión a la base de datos

Extraer el nombre y ubicación de las clases de tipo interfaz

Cerrar conexión

Error de conexión

Falla la conexión

Cerrar conexión

Crear un directorio por cada clase base encontrada

Copiar la clase heredada y ubicarla en el directorio de la clase base

Figura 86. Diagrama de actividad del caso de uso separar el MOO.

121




Separar clases base.



Fecha de creación:


27/02/07

Actores: Usuario y Base de Datos Descripción: Permite al usuario separar las clases base del MOO.

Precondiciones: 1. La etapa de análisis debe de ser finalizada exitosamente. 2. Deben de existir clases base registradas en la base de datos.

Poscondiciones: 1. Se contará con las clases base que forman al marco, separadas por directorios.


1. Se realiza la conexión a la base de datos. 2. Si existen clases base. 3. Se extrae de la base de datos el nombre y ubicación de las

clases base, es decir las que en el campo T_Clase de la tabla clases sea igual a uno.

4. Se guarda la información en un arreglo bidimensional de tipo String.

5. Se cierra la conexión a la base de datos. 6. Para cada clase base se crea un directorio con el nombre de

la clase base encontrada. 7. Se hace una copia de cada clase base y se coloca en el

directorio correspondiente. 8. Termina el proceso.

Escenario de fracaso 1: 1. Se realiza la conexión a la base de datos. 2. Falla la conexión a la base de datos. 3. Se envía un mensaje de error al usuario. 4. Se cierra la conexión. 5. Termina el proceso.

Escenario de fracaso 2: 1. Se realiza la conexión a la base de datos. 2. Si no existen clases base en la base de datos. 3. Se cierra la conexión. 4. Termina el proceso.

Incluye: Suposiciones: Se supone que el usuario cuenta con la base de datos creada y el

sistema original instalado en su máquina.

122



Extraer el nombre y ubicación de las clases base

Cerrar conexión

Error de conexión

Falla la conexión

Cerrar conexión

Crear un directorio por cada clase base encontrada

Copiar cada clase y ubicarla en el directorio correspondiente

Conexión exitosa

Existen clases base

No existen clases base

Guardar información en un arreglo

Figura 87. Diagrama de actividad del caso de uso separar las clases base.



Separar las clases derivadas.



Fecha de creación:


27/02/07

Actores: Usuario y Base de Datos Descripción: Permite al usuario separar las clases derivadas del MOO.

Precondiciones: 1. La etapa de análisis debe de ser finalizada exitosamente.

123


2. Deben de existir clases derivadas registradas en la base de datos.

Poscondiciones: 1. Se contará con las clases derivadas que forman al marco, separadas por directorios.


1. Se realiza la conexión a la base de datos. 2. Si existen clases derivadas en la base de datos. 3. Para cada clase derivada se extrae su nombre y su

ubicación, es decir las que en el campo T_Clase de la tabla clases sea igual a dos.


5. Se extrae el nombre de la clase padre. 6. Mientras la clase padre no sea una clase base. 7. Se sigue verificando el nombre y el tipo de la clase padre

hasta encontrar que T_Clase sea igual a 1, para indicar que es la clase más abstracta en esa jerarquía de herencia.

8. Se verifica el tipo de la clase padre (clase base 1, clase derivada 2, implementación 3).

9. Termina el ciclo mientras. 10. Se guarda el nombre de la clase base en una variable. 11. Se cierra la conexión a la base de datos. 12. Se crea una copia de la clase derivada y se guarda en el

directorio correspondiente a su clase base. 13. Termina el proceso.


Escenario de fracaso 2: 1. Se realiza la conexión a la base de datos. 2. Si no existen clases derivadas. 3. Se cierra la conexión. 5. Termina el proceso.



124




Cerrar conexión

Error de conexión

Falla la conexión

Cerrar conexión

Copiar la clase derivada y ubicarla en el directorio de la clase base

Conexión exitosaExisten clases derivadas

No existen clases derivadas


Extraer el nombre de la clase padre

Extraer el nombre de la clase padre

Si la clase padre no es una clase base

Verificar el tipo de la clase padre

Guardar el nombre de la clase base en una variable

La clase padre es una clase base

Figura 88. Diagrama de actividad del caso de uso separar clases derivadas.

125




Separar las interfaces.



Fecha de creación:


27/02/07

Actores: Usuario y Base de Datos Descripción: Permite al usuario separar las interfaces del MOO.

Precondiciones: 1. La etapa de análisis debe de ser finalizada exitosamente. 2. Deben de existir clases de tipo interfaz registradas en la

base de datos. Poscondiciones: 1. Se contará con las clases derivadas que forman al marco,

separadas por directorios. Escenario de éxito:

1. Se realiza la conexión a la base de datos. 2. Se crea el directorio interfaces. 3. Si existen clases de tipo interfaz. 4. Para cada clase interfaz, es decir las que en el campo

T_Clase de la tabla clases sea igual a tres, se extrae su nombre y ubicación.


6. Se cierra la conexión a la base de datos. 7. Se hace una copia de la clase interfaz y se guarda en el

directorio interfaz. 8. Termina el proceso.


Escenario de fracaso 2: 1. Se realiza la conexión a la base de datos. 2. Se crea el directorio interfases. 3. Si no existen clases de tipo interfaz. 4. Se cierra la conexión. 5. Termina el proceso.



126




Cerrar conexión

Copiar las interfaces al directorio interfaz

Crear el directorio interfaz

Error de conexión

Cerrar conexión

Existen interfaces

No existen interfaces


Conexión exitosa

Falla la conexión

Figura 89. Diagrama de actividad del caso de uso separar interfaces.

3. Módulo de Generación de Servicios Web.



Generar servicios Web.



127


Fecha de creación:


27/02/07

Actores: Usuario y Base de Datos. Descripción: Permite al usuario generar servicios Web con las clases de tipo

implement y las clases base no extendidas. Precondiciones: 1. El usuario debe pulsar el botón generar servicios Web.

2. La fase de análisis debe ser concluida exitosamente. 3. La fase de separación debe ser concluida exitosamente. 4. Deben existir clases base no extendidas en la base de datos. 5. Deben existir clases de tipo implement registradas en la

base de datos 6. Plataforma axis instalada. 7. Servidor tomcat iniciado.

Poscondiciones: 1. Se generan los servicios Web que componen al MOO. Escenario de éxito:

1. El usuario pulsa el botón generar servicios Web. 2. Se realiza la conexión a la base de datos. 3. Se extrae el nombre y la ubicación de las clases de tipo

implement y de las clases base que no son extendidas. 4. Se cierra la conexión a la base de datos. 5. Se crea una copia de los archivos de las clases de tipo

implement y las clases base no extendidas en la carpeta clases del servidor axis.

6. Se compilan las clases del directorio “clases” de axis. 7. Se genera un descriptor de despliegue para cada servicio y se

guarda en la carpeta axis. 8. Se invoca a cada unos de los archivo WSDD. 9. Termina el proceso.

Escenario de fracaso 1: 1. El usuario pulsa el botón generar servicios Web. 2. Se realiza la conexión a la base de datos. 3. Falla la conexión. 4. Termina el proceso.

Escenario de fracaso 2: 1. El usuario pulsa el botón generar servicios Web. 2. Se realiza la conexión a la base de datos. 3. Se extrae el nombre y la ubicación de las clase tipo

implement y de las clases base que no son extendidas. 4. No existen clases de tipo implements, ni clases bases no

extendidas. 5. Se cierra la conexión. 6. Termina el proceso.

Incluye: CU-3.1 Copiar clases, CU-3.2 Compilar clases, CU-3.3 Generar WSDD y CU-3.4 Invocar WSDD.

Suposiciones: Se supone que el usuario cuenta con el sistema original instalado en su máquina, la base de datos creada y el servidor tomcat y la plataforma axis instalados y configurados correctamente.

128


Realizar conexión a la base de datos

Clic en el botón generar servicios Web

Extraer el nombre y ubicación de las clases implements y base no extendidas

Cerrar conexión

Copiar y guardar archivos en el directorio clases de axis

Generar descriptor WSDD

Invocar WSDD

Compilar archivos

Cerrar conexión

Si existen clases

No existen clasesConexión exitosa

Falla conexión

Figura 90. Diagrama de actividad del caso de uso CU-1 Generar servicios.

129




Copiar clases.



Fecha de creación:


27/02/07

Actores: Sistema Descripción: Permite al sistema hacer copias de las clases base e implements y

guardarlas en el directorio “clases” del servidor axis. Precondiciones: 1. Se debe extraer de la base de datos el nombre y ubicación

de las clases implement y las clases base no extendidas. 2. Las clases deben existir en la ubicación especificada. 3. Plataforma axis instalada y configurada correctamente.

Poscondiciones: 1. Se contará con una copia de las clases base e implementaciones en el directorio “clases” del servidor axis.


1. Se crea una copia de los archivos y se guarda en la carpeta “clases” del servidor axis.

2. Termina el proceso. Escenario de fracaso: 1. Se crea una copia de los archivos y se guarda en la carpeta

“clases” del servidor axis. 2. No existen las clases en el directorio origen especificado. 3. Termina el proceso.


su máquina, la base de datos creada y el servidor tomcat y la plataforma axis instalados y configurados correctamente.

Copiar y guardar archivos en el directorio "clases" de axis

Si el directorio origen es correcto

Mensaje de error

Si el directorio origen no es correcto

Figura 91. Diagrama de actividad del caso de uso CU-1.1 Copiar servicios.

130




Compilar clases.



Fecha de creación:


27/02/07

Actores: Usuario Descripción: Permite al sistema compilar las clases.

Precondiciones: 1. El proceso anterior debe ser concluido exitosamente. 2. Los archivos a compilar deben estar libres de errores

lógicos y de compilación. 3. Plataforma axis instalada y configurada correctamente.

Poscondiciones: 1. Se contará con las clases compiladas del directorio clases del servidor axis.


1. Se compilan cada uno de los archivos copiados al directorio clases del servidor axis.

2. Termina el proceso. Escenario de fracaso 1: 1. Se compilan cada uno de los archivos copiados en el

directorio clases del servidor axis. 2. Error de compilación. 3. Termina el proceso.


su máquina, la base de datos creada y el servidor tomcat y la plataforma axis instalados y configurados correctamente.

Compilar archivos del directorio clases de axis

Compilación exitosa

Error de compilación

Falla compilación

Figura 92. Diagrama de actividad del caso de uso CU-1.2 Compilar archivos.

131




Generar WSDD.



Fecha de creación:


27/02/07

Actores: Usuario Descripción: Permite al sistema generar un documento de descripción por cada

servicio Web. Precondiciones: 1. Los procesos anteriores deben ser concluidos exitosamente. Poscondiciones: 1. Se creara un descriptor WSDD por cada servicio Web.


1. Por cada clase copiada y compilada en el directorio clases del servidor axis se genera un documento WSDD con el nombre de la clase y el nombre del servicio.

2. Se guarda el documento WSDD generado en el directorio axis.

3. Termina el proceso. Incluye:

Suposiciones: Se supone que el usuario cuenta con el sistema original instalado en su máquina, la base de datos creada y el servidor tomcat y la plataforma axis instalados y configurados correctamente.

Por cada clase copiada y compilada en el directorio axis generar WSDD

Guardar en el directorio axis

Figura 93. Diagrama de actividad del caso de uso CU-1.4 Generar WSDD.

132




Invocar WSDD.


Elvia Araiza Lzarde

Fecha de creación:


27/02/07

Actores: Sistema Descripción: Permite al sistema invocar al descriptor de despliegue.

Precondiciones: 1. El proceso anterior debe ser concluido exitosamente. 2. Deben existir documentos WSDD generados. 3. Plataforma axis instalada. 4. Servidor tomcat iniciado.

Poscondiciones: 1. Se invocan todos los documentos WSDD. Escenario de éxito:

1. Se obtiene la ubicación de los documentos WSDD

generados. 2. Se ejecuta el comando:

java org.apache.axis.client.AdminClient *.WSDD, con el nombre del servicio Web.

3. Termina el proceso. Incluye:

Suposiciones: Se supone que el usuario cuenta con el sistema instalado en su máquina, la base de datos creada y el servidor tomcat y la plataforma axis instalados y configurados correctamente.

Obtener ubicación de archivos WSDD

Invocar WSDD

Figura 94. Diagrama de actividad del caso de uso CU-1.5 Invocar WSDD.

133

Anexo A. Análisis y diseño del sistema A2. Diseño del Sistema. A2.1. Diagramas de Actividad. 1. Módulo de Análisis.

Ingresar los archivos a analizar

Analizar el código

Identificar caracteristicas de las clase

Limpiar la Base de Datos

Guardar en la Base de Datos la información obtenida

Figura 95. Diagrama de actividades del módulo de análisis del sistema.

134

Anexo A. Análisis y diseño del sistema 2. Módulo de Separación.

Conectar a la base de datos

Extraer nombre y ubicación de las clases bases

Extraer número de clases base en la base de datos

Crear nuevo directorio con el nombre de la clase base

Mientras i<num_clases_base

Copiar la clase, del origen al nuevo directorio

Crear directorio interfacesi=num_clases_base

Extraer número de interfases de la base de datos

Copiar clase, del origen al directorio interfase

Mientras i<num_interfases

Extraer número de clases heredadas

i=num_interfases

Extraer el nombre, ubicación y clase padre

Extraer nombre y ubicación

Copiar clase, desde origen al directorio de la clase padre

Mientras i<num_clases_heredadas

i=num_clases_heredadas

Figura 96. Diagrama de actividades del módulo de análisis del sistema.

135

Anexo A. Análisis y diseño del sistema 3. Módulo de Generación de Servicios Web.

Conectar a la base de datos

Extraer número de clases

Extraer nombre y ubicación de las clases

Copiar las clases al directorio clases de axis

mientras i<num_clases

Compilar las clasesi = num_clases

Crear WSDD

Invocar WSDD

Figura 97. Diagrama de actividades del módulo de generación de servicios.

136

Anexo B. Diseño de prueba y casos de prueba

Anexo B) DISEÑO DE PRUEBA Y CASOS DE PRUEBA

En este anexo se describe el diseño de prueba y los casos de prueba del capítulo 7 de forma detallada. Para la identificación de la nomenclatura de los marcos utilizados para el diseño prueba y para los casos de pruebas revisar la Tabla 6 y la Figura 73. B1. Diseño de Prueba El diseño de pruebas contempla 4 aspectos: • Diseño de Prueba para la Fase de Análisis del Procedimiento. • Diseño de Prueba para la Fase de Separación del Procedimiento. • Diseño de Prueba para la Fase de Generación de Servicios Web del Procedimiento. • Diseño de Prueba para la Fase de Integración de Aplicaciones del Procedimiento. B1.1. Diseño de Prueba para la Fase de Análisis del Procedimiento B1.1.1. Especificación de diseño de prueba: MOO2MSW05-01. Reconocimiento de la sintaxis del código de entrada (código del MOO en estudio) escrito en lenguaje Java.

137

Anexo B. Diseño de prueba y casos de prueba B1.1.2. Características a ser probadas • Reconocimiento exclusivo de las clases desarrolladas en código Java. • Reconocimiento de la ubicación del directorio. • Reconocimiento del nombre de las clases. • Reconocimiento del tipo de la clase. • Reconocimiento de herencia. • Reconocimiento de interfaces. • Reconocimiento de métodos públicos. • Reconocimiento de atributos públicos. • Reconocimiento de relaciones de agregación. • Reconocimiento de implementaciones. • Reconocimiento de clases base. • Almacenamiento correcto de la información. B1.1.3. Refinamientos del enfoque Los elementos incluidos en este estudio de pruebas son los especificados en la gramática del lenguaje Java 1.4, es decir todos aquellos aspectos sintácticos que considere el analizador desarrollado. El usuario selecciona con ayuda de la herramienta, el marco que desea analizar. La herramienta muestra únicamente los archivos con extensión .Java. Se analizan cada una de las clases que integran al marco, reconociendo y extrayendo las características mencionadas en los puntos de 2.1 al 2.12. Después de analizar todas las clases, se almacena la información resultante en una base de datos. Para corroborar que esta etapa se cumplió correctamente, se realiza el análisis sintáctico con la herramienta y se compara manualmente si las características de cada clase guardada en la base de datos corresponden a la información contenida en las clases. B1.1.4. Identificación de pruebas En la Tabla 10 se muestran las características probadas en la fase de análisis para los tres casos de prueba.

Tabla 10. Identificación de pruebas MOO2MSW05-01.

Características de prueba Casos de prueba Ubicación de archivo MOO2MSW06-01, MOO2MSW06-02,

MOO2MSW06-03. Nombre de la clase MOO2MSW06-01, MOO2MSW06-02,

MOO2MSW06-03. Tipo de clase MOO2MSW06-01, MOO2MSW06-02,

MOO2MSW06-03. Herencia MOO2MSW06-01, MOO2MSW06-02,

MOO2MSW06-03. Interfaces MOO2MSW06-01, MOO2MSW06-02,

MOO2MSW06-03. Métodos públicos MOO2MSW06-01, MOO2MSW06-02,

MOO2MSW06-03.

138


Atributos públicos MOO2MSW06-01, MOO2MSW06-02, MOO2MSW06-03.

Relaciones de agregación MOO2MSW06-01, MOO2MSW06-02, MOO2MSW06-03.

Implementaciones MOO2MSW06-01, MOO2MSW06-02, MOO2MSW06-03.

Clase base MOO2MSW06-01, MOO2MSW06-02, MOO2MSW06-03.

Almacenamiento de información MOO2MSW06-01, MOO2MSW06-02, MOO2MSW06-03.

B1.1.5. Criterio pasa / no-pasa de evaluación de características El criterio de evaluación se hace tomando en cuenta la información almacenada en la base de datos. Se verifica tabla por tabla la información almacenada y se compara registro por registro con la información contenida en las clases. De esta forma se verifica que la información almacenada en la base de datos fue identificada y extraída correctamente por el analizador sintáctico. Se considera que un caso de prueba es no válido si la información reflejada en la base de datos no corresponde a la información contenida en una clase. Un caso de prueba debe considerarse válido en los casos en que se reporten fallas, pero éstas se atribuyan a otros elementos que no corresponden a lo que se desea probar. B1.2. Diseño de Prueba para la Fase de Separación del Procedimiento B1.2.1. Especificación de diseño de prueba: MOO2MSW05-02. Localización de racimos de clases del MOO original. B1.2.2. Características probadas • Separación de las clases base. • Separación de las clases derivadas. • Separación de las clases interfaces. B1.2.3. Refinamientos del enfoque El elemento principal requerido en este estudio de pruebas es la base de datos generada. De ella se extrae la información necesaria para separar las clases que integran al marco. La herramienta identifica mediante consultas a la base de datos, el nombre y la ubicación de las clases base (aquellas que no extienden ni implementan a otras clases). Por cada clase base encontrada crea una carpeta con su nombre, hace una copia del archivo .java de la clase original y la pega dentro del directorio creado. Después identifica las clases derivadas (aquellas que presentan en su definición la palabra reservada extends) y mediante una función recursiva encuentra el nombre de la clase base más abstracta en esa jerarquía de herencia, hace una copia del archivo y la pega dentro del directorio de la clase base. Por último identifica las clases interfaces, crea un directorio con el nombre interfaz y copia dentro de el todas las interfaces.

139

Anexo B. Diseño de prueba y casos de prueba Para corroborar que esta etapa se cumple correctamente se verifica que los directorios sean creados y que dentro de ellos se encuentren las clases que deben de estar, según la arquitectura del marco. B1.2.4. Identificación de pruebas

Tabla 11. Identificación de pruebas MOO2MSW05-02. Características de prueba Casos de prueba Clases base, herencia e interfaces MOO2MSW06-01 Directorios MOO2MSW06-01 Copia de clases MOO2MSW06-01

B1.2.5. Criterio pasa / no-pasa de evaluación de características El criterio de evaluación se hace tomando en cuenta los directorios creados y las clases copiadas en los directorios. La clasificación debe corresponder a la arquitectura presentada en el marco. Se considera que un caso de prueba no pasa si:

Se crea un directorio que no debió de haber sido creado. No se crea un directorio que debió haber sido creado. Se copió mal o no se copió una clase dentro del directorio correspondiente. Las clases copiadas presentan problemas al abrirse.

Un caso de prueba se considera como válido en los casos en que se reportan fallas, pero éstas se atribuyan a otros elementos que no corresponden a lo que se desea probar. B1.3. Diseño de Prueba para la Fase de Generación de Servicios Web del Procedimiento B1.3.1. Especificación de diseño de prueba: MOO2MSW05-03. Generación de servicios Web B1.3.2. Características probadas • Identificación de implementaciones y clases base no extendidas y sin

relaciones de agregación. • Copia de las clases al directorio /wepapps/clases de axis. • Compilación correcta de las clases. • Generación de WSDD’s. • Despliegue de WSDD’s. • Sustitución de parámetros de las variables de instancia en los métodos. • Creación de interfaces para llevar jerarquías de herencia a servicios Web. B1.3.3. Refinamientos del enfoque Se verifica que:

140


Las clases base no extendidas y sin relaciones de agregación fueron copiadas al directorio /wepapps/clases de axis.

Los archivos de compilación .class fueron generados. Los archivos WSDD fueron creados y que la información contenida es la correcta. La herramienta no marque error en el momento de desplegar los archivos

WSDD’s. Se abrirá el navegador para verificar que los servicios Web están disponibles en el servidor axis.

Para probar la sustitución de los parámetros de variables de instancia en los métodos que componen a los servicios Web, se implementan técnicas de serialización. Para probar la fase MOO2MSW03-12, en cada caso de prueba se identifican las relaciones de herencia con ayuda de la información desplegada en la herramienta y la clasificación desarrollada en la etapa de separación. Para cada jerarquía de herencia encontrada se desarrolla de forma manual una nueva clase con los métodos y atributos tanto de la clase base como de las clases derivadas y se convierte la nueva clase generada en servicio Web. B1.3.4. Identificación de pruebas

Tabla 12. Identificación de prueba MOO2MSW05-03. Características de prueba Casos de prueba Implementaciones y clases base. MOO2MSW06-01 Copia de las clases al directorio de axis MOO2MSW06-01 Compilación de clases MOO2MSW06-01 Generación de WSDD MOO2MSW06-01 Despliegue de WSDD MOO2MSW06-01 Creación de interfaces MOO2MSW06-01 Generación manual de servicios Web. MOO2MSW06-01

B1.3.5. Criterio pasa / no-pasa de evaluación de características El criterio de evaluación se hace tomando en cuenta si se crearon o no todos los servicios Web posibles en base a la arquitectura del marco. También se verifica en el navegador si los servicios Web son desplegados en el servidor de axis. Además, se crean manualmente clientes para servicios Web que prueban su funcionalidad. Un caso de prueba se considera válido en los casos en que se reportan fallas, pero éstas se atribuyan a otros elementos que no corresponden a lo que se desea probar. B1.4. Diseño de Prueba para la Fase de Integración de Aplicaciones del Procedimiento B1.4.1. Especificación de diseño de prueba: MOO2MSW05-04. Integración de aplicaciones. B1.4.2. Características probadas • Despliegue de las relaciones de agregación existentes. • Sustitución de las relaciones de agregación por integración de aplicaciones.

141

Anexo B. Diseño de prueba y casos de prueba B1.4.3. Refinamientos del enfoque El objetivo de esta fase es cambiar las relaciones de agregación existentes en el marco por integración de aplicaciones. Esta etapa se desarrolla de forma manual por el usuario. Para probar que la etapa se concluyó favorablemente se desarrollan clientes de servicios Web que llaman a los servicios que a la vez internamente utilizan a otros servicios. B1.4.4. Identificación de pruebas

Tabla 13. Identificación de pruebas MOO2MSW05-04. Características de prueba Casos de prueba Despliegue de relaciones. MOO2MSW06-01 Sustitución de relaciones de agregación MOO2MSW06-01

B1.4.5. Criterio pasa / no-pasa de evaluación de características El criterio de evaluación se hará tomando en cuenta que si al invocar un servicio Web que a su vez utiliza la funcionalidad de otro servicio. El resultado que retorna el servicio es el esperado según sea cada caso en particular. Un caso de prueba no se considera válido si el resultado que retorna el servicio Web no es el esperado o si presenta un error de integración. Un caso de prueba debe considerarse válido en los casos en que se reporten fallas, pero éstas se atribuyan a otros elementos que no corresponden a lo que se desea probar. B2. Especificación de Casos de Prueba Los casos de prueba utilizados en esta tesis son 3 y para cada caso de prueba en este anexo se realiza una descripción de la especificación de salida que comprende los siguientes aspectos: a) la fase de análisis del procedimiento. b) la fase de separación. c) la fase de generación de servicios Web. d) la fase de integración de aplicaciones (si el caso de prueba requiere de esta fase). B2.1. Caso de prueba: MOO2MSW06-01 B2.1.1. Especificación de salida a) Salida de la fase de análisis del procedimiento MOO2MSW01-01. Después de pasar el código del marco por el subsistema de análisis MOO2MWS02-01, se refleja en la base de datos como se muestra en las figuras 98, 99 y 100. En la Figura 98 se muestra la tabla en la que se almacenan los nombres de las clases que forman el caso de prueba MOO2MSW06-01 y sus direcciones en disco.

142


Figura 98. Tabla de la base de datos bd, para el caso de prueba MOO2MSW06-01, que contiene información sobre la ubicación de las clases.

En la Figura 99 se muestra la tabla en la que se almacenan: los nombres de las clases; el tipo de acceso (public, private o protected); en el campo T_Metodo se guarda un 1 si en la clase existen uno o más métodos que sean public o protected; en T_Clase se guarda un 1 si se trata de una clase base, un 2 si es una clase derivada y un 3 para las implementaciones; en T_Atributo se guarda un 1 si en la clase existen uno o más atributos que sean public o protected; en Agregacion se guarda un 1 si la clase tiene una o más relaciones de agregación a otra clase; en Super se guarda un 1 si en la clase existe una o más llamada al constructor de la clase padre; en HI se guarda el nombre de la clase o la clase interfaz a la que se extiende, en el caso en el que T_Clase sea una clase derivada se le asigna un 2, ó si es una implementación a una interfaz se le asigna un 3. Por último en interface3 se guarda un 1 si se trata de una clase interfaz.

Figura 99. Tabla de la base de datos bd, para el caso de prueba MOO2MSW06-0, que contiene información

sobre las clases.

3 La palabra interface se utiliza para referirse a las clases tipo interfaz, aquellas que en Java son denominadas interfaces.

143

Anexo B. Diseño de prueba y casos de prueba En la Figura 100 se muestra la tabla de agregación en donde se almacenan los nombres de las clases y las relaciones de agregación que tienen con otras clases.

Figura 100. Tabla de la base de datos bd, para el caso de prueba MOO2MSW06-01, que contiene

información acerca de las relaciones de agregación. b) Salida de la fase de separación MOO2MSW01-02 correspondiente al subsistema de separación MOO2MSW02-02. En el directorio local “C:/” de la computadora local que ejecute la herramienta se generan las carpetas que contienen los conjuntos de archivos generados y organizados por sus tipos (clases base, derivadas e interfaces).

Figura 101. Carpeta ED. Figura 102. Carpeta Lista. Figura 103. Carpeta Elemento.

144


4. Identificar las jerarquías de herencia, crear una nueva clase interfaz y generar servicios Web.

Figura 104. Clase ServicioTendenciaCentral. Figura 105. Carpeta ServicioMetodoOrdenamiento.

Figura 106. Carpeta aCalculoAritmetico.

Figura 107. Carpeta Interface. Un resumen de la salida de la fase de separación que corresponde a las figuras de la 101 a la 107 se muestra a continuación:

Directorios por clase base: ED, Elemento, Lista, ServicioMetodoOrdenamiento, ServicioTendenciaCentral.

Directorio de interfaces: aAlgoritmo, aCalculoDispersion, aCalculoTendencia, aOrdenamiento y aRegresion.

Directorios para relaciones de herencia a aCalculoAritmetico: cProductosSucesivos, cSuma, cSumatorias y cSumatoriaCuadrados.

c) Salida de la fase de generación de servicios Web MOO2MSW01-03 correspondiente al subsistema de separación MOO2MSW02-03. La salida de esta fase se divide en las siguientes cuatro actividades:

1. Identificación de clases base no extendidas y sin relaciones de agregación e implementaciones.

2. Creación de los archivos de despliegue WSDD por cada clase a convertir a servicio.

3. Despliegue de los archivos WSDD.

145


1. imp dentificadas con MOO2MSW03-08.

al directorio “clases” del rvidor axis para su compilación identificadas con MOO2MSW03-09.

Figura 108. Carpeta clases del servidor axis. En la Figura 108 se idor axis, el cual contiene

clase ED del caso de prueba MOO2MSW06-01. La clase ED es una clase base no

s archivos de despliegue WSDD por cada clase a convertir a servicio.

muestra la dirección del servidor axis, en la cual se guarda el documento de despliegue WSDD para generar el servicio Web ED.

is del servicio Web ED y

sus métodos: _SetVal1, _SetVal2, _GetVal1, _GetVal2 y _Show.

Identificación de clases base no extendidas y sin relaciones de agregación e lementaciones, i

En esta actividad se copian los archivos de las clases

se

muestra el directorio “clases” del servlaextendida y sin relaciones de agregación.

2. MOO2MSW03-11. Creación de lo

En la Figura 109 se

Figura 109. Directorio axis.

3. MOO2MSW03-11. Despliegue de los archivos WSDD.

En la Figura 110 se muestra el despliegue en el servidor ax

146


4. MOO2MSW03-12 ncia, creación de clases

interfaz nuevas y generación de servicios Web. OO cuya clase base es una clase oncrete es la que corresponde a los Cálculos aritméticos como se muestra en la Figura 11.

El sistema rec correspondientes a los cálculos aritméticos y las despliega en pantalla como se muestra en la Figura 112.

Figura 112. Re MSW06-01.

Figura 110. Despliegue del servicio Web ED.

. Identificación de jerarquías de here

La única jerarquía de herencia presente en el Mc1

Figura 111. Jerarquía de clases para Cálculos aritméticos.

onoce las jerarquías de herencia de la Figura 111

laciones de herencia presentes en el caso de prueba MOO2

147

Anexo B. Diseño de prueba y casos de prueba D

Figura 113. Clase ServicioCalculoAritmetico. En la Figura 113 se muestra la clase “ServicioCalculoAritmetico” que funciona como interfaz y que facilita el reconocimiento de los métodos de la jerarquía de herencia de los cálculos aritméticos. La jerarquía de herencia pasa completamente al servidor y es accedida a través de la clase “ServicioCalculoAritmetico”. El método Calcular() implementado en las clases: cSumatoria, cProductosSucesivos, cSumatoriaCuadrados y cSuma, recibe como parámetro de entrada

espués de reconocer las jerarquías de herencia se debe crear manualmente unaclase interfaz que se muestra en la Figura 113, que permitirá tener en un servicio Web todos los métodos de la jerarquía de herencia.

import java.io.ByteArrayInputStream; import java.io.IOException; import java.io.ObjectInputStream; p blic class ServicioCalculoAritmetico{ public ServicioCalculoAritmetico() { } public float SumatoriaCuadrados(byte[] b, int valor) throws IOException, ClassNotFoundException { Lista l; l= leerobjeto(b); aCalculoAritmetico aca = new cSumatoriaCuadrados(); return aca.Calcular(l, valor); } public float Sumatoria(byte[] b, int valor) throws IOException, ClassNotFoundException { Lista l; l=leerobjeto(b); aCalculoAritmetico aca = new cSumatoria(); return aca.Calcular(l, valor); } public float ProductosSucesivos(byte[] b, int valor) throws IOException, ClassNotFoundException { Lista l; l=leerobjeto(b); aCalculoAritmetico aca = new cProductosSucesivos(); return aca.Calcular(l, valor); } public float Sumar(float f1, float f2) { aCalculoAritmetico aca = new cSuma( ); return aca.Calcular(f1,f2); } public Lista leerobjeto(byte[] b) throws IOException, ClassNotFoundException { ByteArrayInputStream bs= new ByteArrayInputStream(b); ObjectInputStream is = new ObjectInputStream(bs); Lista d = (Lista)is.readObject(); is.close(); return d; } }

Invocación al método Calcular de la clase cSumatoriaCuadrados

u

Invocación al método Calcular de la clase cSumatoria

Invocación al método Calcular de la clase cProductosSucesivos

Invocación al método Calcular de la clase cSuma

148


149

en la clase original un objeto de tipo Lista. Para poder tratar estos métodos es necesario utilizar Serialización de objetos. Después se crea el servicio Web con la clase generada manualmente “ServicioCalculoAritmetico” y se despliega en el servidor axis como se muestra en la Figura 114. Para probar que el servicio funciona correctamente se puede generar un cliente como el de la Figura 115, y en la Figura 116 se muestra el resultado de ejecutar el cliente.

Figura 11 etico.

Figura 115. Clase Cliente.

import java.io.IOException; import localhost.axis.services.ServicioCalculoAritmetico.*; public class Cliente { public static void main(String[] args) throws IOException, ClassNotFoundException { byte [] bytes; float l; int i = 1; Lista L1 = new Lista(null,null); ED Edatos2 = new ED((float)2.0,(float)2.0); Elemento E2 = new Elemento(Edatos2, null, null); L1._Agrega(E2); ED Edatos1 = new ED((float)5.0, (float)5.0); Elemento E1 = new Elemento(Edatos1, null, null); L1._Agrega(E1); SerializarLista imp = new SerializarLista(); bytes = imp.writeObject(null,L1); localhost.axis.services.ServicioCalculoAritmetico.ServicioCalculoAritmeticoServiceLocator locator; localhost.axis.services.ServicioCalculoAritmetico.ServicioCalculoAritmetico calc; try { locator = new ServicioCalculoAritmeticoServiceLocator(); calc = locator.getServicioCalculoAritmetico(); //Conexión al servicio Web. l = calc.sumatoria(bytes,i); //Invocación al método sumatoria del servicio. System.out.println("Valor resultado" + l); System.out.println("Valor resultado" + calc.sumar(2,2)); //Invocación al método sumar. l = calc.sumatoriaCuadrados(bytes,i); //Invocación al método SumatoriaCuadrados. System.out.println("Valor resultado" + l); l = calc.productosSucesivos(bytes,i); //Invocación al método productosSucesivos. System.out.println("Valor resultado " + l); } catch (Exception ex){ System.out.println(ex); } } }

4. Despliegue del servicio Web ServicioCalculoAritm


150

Figura 116. Resultado de ejecutar la clase Cliente.

d) Salida de la fase de integración de aplicaciones MOO2MSW01-04 correspondiente al subsistema de separación MOO2MSW02-04. 1) Clases que implementan interfaces y que tienen relaciones de asociación. Este caso es el presentado en la fase de Integración de aplicaciones en el capítulo 5 “Definición del Procedimiento”, en el que se especifica que no serán generados de forma automática los servicios Web a partir de clases que contengan relaciones de asociación. • La Figura 117 muestra un ejemplo de clases que implementan métodos de

ordenamiento (cQuickSort, cBurbuja, etc.). Estas clases tienen una relación de asociación con las clases Elemento y ED. Analizando visualmente el código de las clases se puede ver que el acceso a Elemento y ED se encuentra dentro de un ciclo como se muestra en la Figura 118, de tal manera que si Elemento y ED estuvieran implementados como servicios Web, y desde un servicio cliente se invocara a Elemento y ED, se estaría haciendo una petición a los servicios varias veces por cada elemento contenido en la Lista, lo cual afecta de manera considerable el rendimiento en cuanto al tiempo de respuesta de cada servicio e incrementa el consumo de red. Es por eso que se tomó la decisión de no separar en dos servicios diferentes la parte del manejo de la Lista (clases Lista, Elemento y ED) y la parte de los métodos de ordenamiento.

Figura 117. Jerarquía de clases para Cálculos de ordenamiento.


151

Figura 118. Ejemplo de llamadas recurrentes en un cliente hacia los servicios Elemento y ED. La solución dada consiste en dejar el manejo interno de las clases, sin integración de aplicaciones a los servicios Lista, Elemento y ED. Es decir, dejar las clases Lista, Elemento y ED, contenidas en el servidor de servicios Web para que las clases: cSelecciónDirecta, cShaker, cInsercionDirecta, cBurbuja, cShellSort, cQuickSort y cMerge puedan acceder a ellas de manera interna como clases y no como servicios.

Figura iento. En la Figura 119 se muestran los servicios Web generados a partir de la jerarquía de herencia de la Figura 117.

Elemento E; ED Aux; for (i = 0; i < l.numElementos() - 1; i++) { E = l._GetH(); for (j = 0; j < l.numElementos() - i - 1; j++) { if (((E._GetNext().GetED()._GetVal1() < E.GetED()._GetVal1()) && tipo == true) ||

((tipo == false && (E._GetNext().GetED()._GetVal1() > E.GetED()._GetVal1())))) { Aux = E._GetNext().GetED(); E._GetNext()._SetED(E.GetED()); E._SetED(Aux); } E = l._Proximo(E); } }

119. Servicios Web de métodos de ordenam


152

• La Figura 120 muestra un ejemplo de clases que implementan cálculos de regresión (cRegLieal, cRegCuadrada, etc.). Estas clases tienen una relación de asociación con las clases Elemento y ED. Analizando visualmente el código de las clases se puede ver que el acceso a Elemento y ED se encuentra dentro de un ciclo como se muestra en la Figura 118, de tal manera que si Elemento y ED estuvieran implementados como servicios Web, y desde un servicio cliente se invocara a Elemento y ED, se estaría haciendo una petición a los servicios varias veces por cada elemento contenido en la Lista, lo cual afecta de manera considerable el rendimiento en cuanto al tiempo de respuesta de cada servicio e incrementa el consumo de red. Es por eso que se tomó la decisión de no separar en dos servicios diferentes la parte del manejo de la Lista (clases Lista, Elemento y ED) y la parte de cálculos de regresión.

La solución dada consiste en dejar el manejo interno de las clases, sin integración de aplicaciones a los servicios Lista, Elemento y ED. Es decir, dejar las clases Lista,

Figura 120. Jerarquía de clases para Cálculos de regresión.


153

Elemento y ED, contenidas en el servidor de servicios Web para que las clases: cRegLienal, cRegCuadratica, cRegPotencial y cRegExponencial puedan acceder a ellas de manera interna como clases y no como servicios.

Figur ón. En la Figura 121 se muestran los servicios Web generados a partir de la jerarquía de herencia de la Figura 120. • La Figura 122 muestra un ejemplo de clases que implementan cálculos de tendencia

central (cMediaCuadrada, cMediaAritmetica, etc.). Estas clases tienen una relación de asociación con las clases Elemento y ED. Analizando visualmente el código de las clases se puede ver que el acceso a Elemento y ED se encuentra dentro de un ciclo como se muestra en la Figura 118, de tal manera que si Elemento y ED estuvieran implementados como servicios Web, y desde un servicio cliente se invocara a Elemento y ED, se estaría haciendo una petición a los servicios varias veces por cada elemento contenido en la Lista, lo cual afecta de manera considerable el rendimiento en cuanto al tiempo de respuesta de cada servicio e incrementa el consumo de red. Es por eso que se tomó la decisión de no separar en dos servicios diferentes la parte del manejo de la Lista (clases Lista, Elemento y ED) y la parte de cálculos de tendencia central.

a 121. Servicios Web de cálculos de regresi


La solución dada consiste en dejar el manejo interno de las clases, sin integración de aplicaciones a los servicios Lista, Elemento y ED. Es decir, dejar las clases Lista, Elemento y ED, contenidas en el servidor de servicios Web para que las clases: cMediaCuadrada, cMediaAritmetica, cModa, cMediaArmonica y cMediana puedan acceder a ellas de manera interna como clases y no como servicios.

Figura ia central.

En la Figur de la jerarquía de erencia de la Figura 122.

un ejemplo de clases que implementan cálculos de dispersión (cCoheficiente, cCovarianza, etc.). Estas clases tienen una relación de asociación con

Figura 122. Jerarquía de clases para Cálculos de tendencia central.

123. Servicios Web de los cálculos de tendenc

a 123 se muestran los servicios Web generados a partirh • La Figura 124 muestra

las clases Elemento y ED. Analizando visualmente el código de las clases se puede ver que el acceso a Elemento y ED se encuentra dentro de un ciclo como se muestra en la Figura 118, de tal manera que si Elemento y ED estuvieran implementados como

154


haciendo u

La solución dada consiste en dejar el manejo interno de las clases, sin integración de aplicaciones a los servicios Lista, Elemento y ED. Es decir, dejar las clases Lista, Elemento y ED, contenidas en el servidor de servicios Web para que las clases: cCoheficiente, cCovarianza, cDesviacionEstandar, cDesviacionMedia, cRango y cVarianza puedan acceder a ellas de manera interna como clases y no como servicios.

Figura 125. spersión.

En la Figura 125 muestran los servicios Web generados a partir de la jerarquía de herencia de la Figura 124.

servicios Web, y desde un servicio cliente se invocara a Elemento y ED, se estaría na petición a los servicios varias veces por cada elemento contenido en la

Lista, lo cual afecta de manera considerable el rendimiento en cuanto al tiempo de respuesta de cada servicio e incrementa el consumo de red. Es por eso que se tomó la decisión de no separar en dos servicios diferentes la parte del manejo de la Lista (clases Lista, Elemento y ED) y la parte de cálculos de dispersión.

Figura 124. Jerarquía de clases para Cálculos de dispersión.

Servicios Web de cálculos de di

155


156

• La Figura 126 muestra un ejemplo de las clases base ServicioMetodoOrdenamiento y ServicioTendenciaCentral. Estas clases tienen una relación de asociación con las clases Elemento y ED. Analizando visualmente el código de las clases se puede ver que el acceso a Elemento y ED se encuentra dentro de un ciclo como se muestra en la Figura 118, de tal manera que si Elemento y ED estuvieran implementados como servicios Web, y desde un servicio cliente se invocara a Elemento y ED, se estaría haciendo una petición a los servicios varias veces por cada elemento contenido en la Lista, lo cual afecta de manera considerable el rendimiento en cuanto al tiempo de respuesta de cada servicio e incrementa el consumo de red. Es por eso que se tomó la decisión de no separar en dos servicios diferentes la parte del manejo de la Lista (clases Lista, Elemento y ED) y la parte de las clases ServicioMetodoOrdenamiento y ServicioTendeciaCentral.

La solución dada consiste en dejar el manejo interno de las clases intactas, sin integración de aplicaciones a los servicios Lista, Elemento y ED. Es decir, dejar las clases Lista, Elemento y ED, contenidas en el servidor de servicios Web para que las clases: ServicioMetodoOrdenamiento y ServicioTendenciaCentral puedan acceder a ellas de manera interna como clases y no como servicios.

En la Figura 127 se muestran los servicios Web generados a partir de la arquitectura de clases de la Figura 126.

Figura 127. Servicio Web MetodoOrdenamiento.

Figura 126. Jerarquía de clases para ServicioMetodoOrdenamiento y ServicioTendenciaCentral.


157

• La Figura 128 muestra un ejemplo de clases base Lista, Elemento y ED. Analizando visualmente el código de las clases se puede ver que la clase Elemento, tiene una relación de agregación a la clase ED, además, contiene el método GetED de tipo ED. La clase Lista, tiene métodos de tipo Elemento y otros métodos en los que dentro de un ciclo se invoca a la clase Elemento. Debido a estos aspectos para que los servicios Web pueden ser funcionales, deben tener acceso a las clases Elemento y ED. Es por eso que se tomó la decisión de no separar en dos servicios diferentes la parte del manejo de Elemento y ED.

Fi En la Figura 129 se muestran los servicios Web generados a partir de la jerarquía de herencia de la Figura 128.

gura 129. Servicios Web Lista y Elemento.

Figura 128. Jerarquía de clases para las clases Lista y Elemento.

EDVal1 : floatVal2 : float

ED()_SetVal1()_SetVal2()_GetVal1()_GetVal2()_Show()

Elemento

Elemento()GetED()_SetED()_GetNext()_ApuntaSigi()_GetPrev()_ApuntaPrev()_ApuntaPrevNext()_ApuntaNextPrev()

+eDatos

Prev

Next

ListanElementos : int

Lista()_GetH()numElementos()_GetC()_GetAux()_SetH()_SetC()_SetAux()_IsEmpty()_Agrega()_Apila()_Inserta()_Borra()_Proximo()_Anterior()_Despliega()

+H+C+Aux


158

B2.2. Caso de prueba: MOO2MSW06-02 El diagrama de clases correspondiente al caso de prueba MOO2MSW06-02 se muestra en la Figura 77. B2.2.1. Especificación de salida a) Salida de la fase de análisis MOO2MSW01-02. Después de pasar el código del marco por el subsistema de análisis MOO2MWS02-02, se refleja en la base de datos como se muestra en las figuras: Figura 130, Figura 131y Figura 132. En la Figura 130 se muestra la tabla en la que se almacenan los nombres de las clases que forman el caso de prueba MOO2MSW06-02 y sus direcciones en disco.

Fi n

En la Figura 131 se muestra la tabla que almacenan: los nombres de las clases; el tipo de acceso (public, private o protected); en el campo T_Metodo se guarda un 1 si en la clase existen uno o más métodos que sean public o protected; en T_Clase se guarda un 1 si se trata de una clase base, un 2 si es una clase derivada y un 3 para las implementaciones; en T_Atributo se guarda un 1 si en la clase existen uno o más atributos que sean public o protected; en Agregacion se guarda un 1 si la clase tiene una o más relaciones de agregación a otra clase; en Super se guarda un 1 si en la clase existe una o más llamada al constructor de la clase padre; en HI se guarda el nombre de la clase o la clase interfaz a la que se extiende, en el caso en el que T_Clase sea una clase derivada se le asigna un 2, ó si es una implementación se le asigna un 3. Por último en interface se guarda un 1 si se trata de una clase interfaz.

gura 130. Tabla de la base de datos bd del caso de prueba MOO2MSW06-02, que guarda informacióacerca de la ubicación de las clases.

Figura 131. Tabla de la base de datos bd del caso de prueba MOO2MSW06-02, que guarda información

sobre las clases. En la Figura 132 se muestra la tabla de agregaciones en donde se almacenan los nombres de las clases y las relaciones de agregación que tiene hacia otras clases.


159

Figura 132. Tabla de la base de datos bd para el caso de prueba MOO2MSW06-02, que guarda información

sobre las relaciones de agregación. b) Salida de la fase de separación MOO2MSW01-02 correspondiente al subsistema de separación MOO2MSW02-02. En el directorio local “C:/” de la computadora local que ejecute la herramienta se generan las carpetas que contendrán los conjuntos de archivos generados y organizados por sus tipos (clases base, derivadas e interfaces).

Figura W06-02. nerada para el caso de prueba MOO2MSW06-02. c) Salida de la fase de generación de servicios Web MOO2MSW01-03 correspondiente al subsistema de generación MOO2MSW02-03. La salida de esta fase se divide en las siguientes cuatro actividades:

1. Identificación de clases base no extendidas y sin relaciones de agregación e implementaciones.

2. Creación de los archivos de despliegue WSDD por cada clase a convertir a servicio.

3. Despliegue de los archivos WSDD. 1. Identificación de clases base no extendidas y sin relaciones de agregación e

implementaciones, identificadas con MOO2MSW03-08. En esta actividad se copian los archivos de las clases al directorio “clases” del servidor axis para su compilación, identificadas con MOO2MSW03-09.

133. Carpeta interface para el caso de prueba MOO2MS

En la Figura 133 muestra el ejemplo de la carpeta interface ge


160

las clases: cCirculo, cElipse, cCuadro, cParalelogramo, cTrapezoide y cRectangulo del caso de prueba MOO2MSW06-01. Estas clases son implementaciones de la interfaz aFigura.

2. MOO2MSW03-10. Creación de los archivos de despliegue WSDD por cada clase a convertir a servicio.

En la Figura 135 se muestra la dirección del servidor axis, en la cual se guardan los documentos de despliegue WSDD para generar los servicios Web (descritos en el procedimiento): cCirculo, cElipse, cCuadro, cParalelogramo, cTrapezoide y cRectangulo.

Figura 135. Directorio axis para el caso de prueba MOO2MWS06-02.

Figura 134. Carpeta clases des servidor axis para el caso de prueba MOO2MSW06-02.

En la Figura 134 se muestra el directorio “clases” del servidor axis, el cual contiene


161

En la Figura 136 se muestra un ejemplo del archivo WSDD para generar el servicio Web cCirculo.

Figura 136. Ejemplo de un el documento WSDD del servicio Web cCirculo.

3. MOO2MSW03-11. Despliegue de los archivos WSDD.

En la Figura 137 se muestra el despliegue de los servicios Web: cCirculo, cElipse, cCuadro, cParalelogramo, cTrapezoide y cRectangulo y su método area.

Figura 137. Servicios Web de figuras geométricas. B2.3. Caso de prueba: MOO2MS El diagramala Figura 80. B2.3.1. Especificación de salida Este caso es sim ente se describe la fase del procedimEn el caso de prueba MOO2MS rarquía de herencia es una clase interfaz mientras q

<deployment xmlns="http://xml.apache.org/axis/WSDD/" xmlns:java="http://xml.apache.org/axis/WSDD/providers/java"> <service name="cCirculo" provider="java:RPC"> <parameter name="className" value="cCirculo"/> <parameter name="allowedMethods" value="*"/> </service> </deployment>

W06-03

de clases correspondiente al caso de prueba MOO2MSW06-03 se muestra en

ilar al caso de prueba MOO2MSW06-02, por lo que únicamiento en la que más se refleja la diferencia entre los dos casos.

W06-02 la clase base de la jeue en este caso es una clase concreta.


162

a) Salida de la fase de generación de servicios Web MOO2MSW01-03 correspondiente al subsistema de generación MOO2MSW02-03.

1. MOO2MSW03-12. Análisis para identificar las jerarquías de herencia, crear una nueva interfaz y generar servicio Web.

Después de la etapa de este análisis al desplegar la información de las relaciones de herencia, se identifica que se trata de una jerarquía de herencia en la que todas las clases son derivadas de la clase aFigura, como se puede ver la Figura 138, en la que se muestra el nombre de la clase, su directorio y la clase a la que extiende o de la que deriva.

Figura 138. Relaciones de herencias presentes en el caso de prueba MOO2MSW06-03.

El siguiente paso según la especificación del procedimiento, es crear manualmente una clase que sirva de interfaz para la generación del servicio Web. En este caso la clase se denominó ServiciosFigurasGeometricas y su código es el siguiente:

Figura 139. Clase ServicioFigurasGeometricas.

public class ServicioFigurasGeometricas { public double areacirculo(int x, int y, double radio){ double resultado; aFigura area = new cCirculo(x,y,radio); resultado = area.area(); return resultado; } public double areacuadrado(int x, int y, double lad){ return } public d return resultado; } public double areaparalelogramo(int x, int y, double bas, double h1){ double resultado; aFigura area = new cParalelogramo(x,y,bas,h1); resultado = area.area(); return resultado; } … }

double resultado; aFigura area = new cCuadrado(x,y,lad); resultado = area.area(); resultado;

ouble areaelipse(int x, int y, double rad1, double rad2){ double resultado;

aFigura area = new cElipse(x,y,rad1, rad2); resultado = area.area();

Anexo B. Diseño de prueba y casos de prueba En la Figura 139 se muestra la clase “ServicioFigurasGeometricas” que funciona como interfaz y que facilita el reconocimiento de los métodos de la jerarquía de herencia de las figuras geométricas. La jerarquía de herencia pasa completamente al servidor y es accedida a través de la clase “ServicioFigurasGeometricas”. El siguiente paso es la conversión a servicio Web de la clase “ServicioFigurasGeometricas” creada manualmente. Para este proceso la herramienta muestra la opción de generación de servicios de forma semiautomática. Pero antes de utilizar la opción se deben de copiar todos los archivos del marco con extensión .class a la carpeta clases de axis para que el proceso de conversión no presente errores.

Figura 140. Directorio axis para el caso de prueba MOO2MSW06-03.

En la Figura 141 se muestra el servicio Web generado a partir de la clase “ServicioFigurasGeometricas” de la Figura 139 con los métodos: areacirculo, areacuadrado, areaelipse, areaparalelogramo, arearectangulo y areatrapezoide.

Figura 141. Servicio Web ServicioFigurasGeometricas.

163

tabla de contenido · listado de figuras figura 1. marco orientado a objetos del dominio de la...

Documents